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ABSTRACT 


The  harsh  radiation  environment  of  space,  the  propensity  for  SEUs  to  per¬ 
turb  the  operations  of  a  silicon  based  electronics,  the  rapid  development  of  mi¬ 
croprocessor  capabilities  and  hence  software  applications,  and  the  high  cost 
(dollars  and  time)  to  develop  and  prove  a  system,  require  flexible,  reliable,  low- 
cost,  rapidly-developed  system  solutions.  Consequently,  a  reconfigurable  Triple 
Modular  Redundant  (TMR)  System-on-a-Chip  (SOC)  utilizing  Field  Programma¬ 
ble  Gate  Arrays  (FPGAs)  provides  a  viable  solution  for  space  based  systems. 
The  Configurable  Fault  Tolerant  Processor  (CFTP)  is  such  a  system,  designed 
specifically  for  the  purpose  of  testing  and  evaluating,  on  orbit,  the  reliability  of  in¬ 
stantiated  TMR  soft-core  microprocessors,  as  well  as  the  ability  to  reconfigure 
the  system  to  support  any  onboard  processor  function. 

The  CFTP  maximizes  the  use  of  Commercial  Off-The-Shelf  (COTS)  tech¬ 
nology  to  investigate  a  low-cost,  flexible  alternative  to  processor  hardware  archi¬ 
tecture,  with  a  Total  Ionizing  Dose  (TID)  tolerant  FPGA  as  the  basis  for  a  SOC. 
The  flexibility  of  a  configurable  processor,  based  on  FPGA  technology,  will  en¬ 
able  on-orbit  upgrades,  reconfigurations,  and  modifications  to  the  architecture  in 
order  to  support  dynamic  mission  requirements. 

The  CFTP  payload  consists  of  a  Printed  Circuit  Board  (PCB)  of  5.3  inches 
x  7.3  inches  utilizing  a  slightly  modified  PC/104  bus  interface.  The  initial  FPGA 
configuration  will  be  an  instantiation  of  a  TMR  processor,  with  included  Error  De¬ 
tection  and  Correction  (EDAC)  and  memory  controller  circuitry.  The  PCB  is  de¬ 
signed  with  requisite  supporting  circuitry  including  a  configuration  controller 
FPGA,  SDRAM,  and  Flash  memory  in  order  to  allow  the  greatest  variety  of  pos¬ 
sible  configurations. 

The  CFTP  is  currently  manifested  as  a  Space  Test  Program  (STP)  ex¬ 
perimental  payload  on  the  Naval  Postgraduate  School’s  NPSAT1  and  the  United 
States  Naval  Academy’s  MidSTAR-1  satellites. 
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EXECUTIVE  SUMMARY 


The  space  environment  presents  numerous  hazards  to  electronic  sys¬ 
tems.  Particularly,  the  effects  of  radiation  can  cause  catastrophic  problems.  To¬ 
tal  Ionizing  Dose  (TID)  effects  contribute  to  the  deterioration  of  a  device  over 
time,  and  Single  Event  Effects  (SEEs)  are  those  radiation  effects  that  occur  un- 
predictably  with  a  wide  range  of  consequences.  Many  manufacturing  techniques 
and  mitigation  schemes  exist  to  alleviate  or  reduce  the  effects  of  radiation,  both 
TID  and  SEE.  Although  some  devices  are  specifically  manufactured  to  perform 
in  the  radiation  environment,  they  tend  to  sacrifice  performance,  at  a  higher  cost, 
compared  to  state-of-the-art  Commercial-Off-The-Shelf  (COTS)  devices. 

Field  Programmable  Gate  Arrays  (FPGAs)  are  available  as  both  Radiation 
Hardened  (RADHARD)  and  COTS  devices.  They  are  comprised  of  thousands  to 
millions  of  tiny  programmable  logic  elements,  each  capable  of  performing  a  logic 
function,  in  a  sea  of  interconnects.  Combining  the  TID  tolerance  of  the  RAD¬ 
HARD  FPGAs  with  various  mitigation  schemes,  FPGAs  have  the  potential  to  per¬ 
form  adequately  in  space.  Considering  that  an  FPGA  can  be  configured  to  per¬ 
form  the  functions  of  COTS  processors,  it  now  becomes  possible  to  provide 
COTS  functionality  in  a  RADHARD  device. 

Applying  the  reconfigurability  of  RADHARD  FPGAs  to  the  space  industry 
provides  a  tool  for  engineers  to  overcome  some  of  the  constraints  that  are  im¬ 
posed  on  systems  designers.  First,  systems  can  now  be  designed  using  FPGAs 
using  the  most  current  configuration  of  a  processor.  As  processor  technology 
advances  the  FPGA’s  configuration  can  be  upgraded,  not  only  prior  to  launch, 
but  conceivably  throughout  the  orbital  life  of  the  system.  Also,  families  of  sys¬ 
tems  that  are  replenished  over  the  long  periods  of  time,  for  example  the  Global 
Positioning  System  (GPS)  constellation,  can  be  designed  with  FPGAs  allowing 
for  design  changes  eliminating  the  need  to  set  processor  technology  years  or 
even  decades  earlier  than  the  last  planned  launch.  On-board  systems  would  no 


XVII 


longer  be  required  to  be  backward  compatible,  as  the  existing  systems  would 
simply  be  updated  to  match  the  latest  technology. 

The  Configurable  Fault-Tolerant  Processor  (CFTP)  is  a  system  that  has 
been  designed  from  the  beginning  with  many  of  these  goals  in  mind.  It  is  cen¬ 
tered  on  the  concept  of  instantiating  a  Triple  Modular  Redundant  (TMR)  micro¬ 
processor  as  a  System-On-A-Chip  (SOC),  to  provide  COTS-like  performance,  at 
low-power  and  cost,  for  on-orbit  applications.  The  CFTP’s  objectives,  centered 
on  the  concept  of  reliable,  reconfigurable,  computing  in  space,  were  the  starting 
point  for  this  research.  The  result  has  been  the  design  and  development  of  the 
CFTP’s  architecture,  culminating  in  the  delivery  of  a  Printed  Circuit  Board  (PCB). 
The  CFTP,  through  the  Space  Test  Program  (STP),  has  been  manifested  on  the 
Naval  Postgraduate  School  Satellite  1  (NPSAT1)  and  the  United  States  Naval 
Academy’s  (USNA’s)  Midshipmen  Science  and  Technology  Application  Research 
Mission  1  (MidSTAR-1),  both  to  be  launched  in  2006. 

The  development  of  the  CFTP  from  a  conceptual  plan  of  a  reconfigurable 
SOC  to  a  full  system  followed  three  concurrent  and  mutually  dependant  proc¬ 
esses.  Component  parts  were  assessed  and  selected  while  the  architecture  was 
being  developed  and  the  functionality  of  the  system  was  being  determined. 
Changes  in  one  of  the  processes  required  changes  in  the  other  two.  The  final 
selection  of  parts,  however,  determined  the  end  state  architecture  and  functional¬ 
ity. 

Designed  around  FPGAs,  the  CFTP  utilizes  Xilinx  RADHARD  Static  Ran¬ 
dom  Access  Memory  (SRAM)  FPGAs  to  provide  TID-tolerant  reconfigurable  ar¬ 
chitecture.  Supporting  the  FPGAs  are  Synchronous  Dynamic  Random  Access 
Memory  (SDRAM),  Programmable  Read  Only  Memory  (PROM),  and  Electrically 
Erasable  PROM  (EEPROM),  as  well  as  discrete  devices  including  resistors,  ca¬ 
pacitors  and  voltage  regulators,  and  an  oscillator.  The  SDRAM  provides  system 
memory  for  the  normal  functioning  of  the  system  as  a  processor.  The  EEPROM 
and  PROM  provide  configuration  storage  for  the  two  FPGAs.  Using  an  elaborate 
interconnection  architecture  between  the  CFTP’s  devices  provides  maximum 


flexibility  in  both  how  the  devices  are  configured  and  how  the  devices  communi¬ 
cate  between  each  other.  Because  the  FPGAs  can  be  configured  for  infinite 
functions,  providing  a  robust  interconnection  architecture  allows  the  greatest  op¬ 
tions  for  future  configurations. 

Through  this  research,  the  required  flexible  architecture  has  been  de¬ 
signed  using  reliable  components,  in  order  to  provide  COTS-like  reconfigurable 
performance.  Using  this  architecture  and  carefully  selected  components,  the 
CFTP  PCB  has  gone  from  concept  to  hardware,  ready  now  for  the  next  step  in 
preparation  for  satellite  integration  and  eventual  launch. 

Further  research  is  required  to  design  suitable  configurations  for  the  vari¬ 
ous  controllers  required  by  the  two  FPGAs,  as  well  as  configuration  for  state-of- 
the-art  follow-on  processors,  which  will  provide  the  aforementioned  COTS-like 
performance.  The  next  step,  however,  is  to  validate  the  architecture  and  meth¬ 
ods  for  configuration,  and  begin  space  suitability  analysis. 
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I.  INTRODUCTION 


Utilizing  microelectronic  devices  in  space  requires  that  engineers  use 
highly  specialized  and  very  expensive  parts  in  order  to  survive  the  harsh  envi¬ 
ronment.  Modern  applications,  including  Digital  Signal  Processing  (DSP)  and 
image  compression,  demand  significant  processing  power  and  speed,  as  well  as 
increased  complexity  of  the  host  system  architecture  for  those  satellites  being 
launched  today.  Unfortunately,  since  the  end  of  the  cold  war  the  Department  of 
Defense  (DOD)  and  the  commercial  electronics  industry  have  been  steadily  re¬ 
ducing  research  and  development  investment  into  the  radiation  hardening  and 
reliability  of  microelectronics,  deferring  to  the  more  lucrative  consumer  electron¬ 
ics  markets.  Consequently,  the  radiation  hardened  parts  available  lag  state-of- 
the-art  technology  by  one  or  more  generations.  Further  exacerbating  the  prob¬ 
lem  is  that  the  space  industry  has  become  more  commercialized  and  accessible 
to  companies  outside  of  the  DOD,  tending  to  scale  down  satellite  sizes  and 
budgets,  while  satellite-building  competition  has  increased.  The  results  of  the 
above  factors  are  simply  that  the  space  industry  can  no  longer  afford  to  exclu¬ 
sively  use  radiation-hardened  parts  designed  specifically  for  space  applications. 

In  addition  to  the  problems  associated  with  designing  for  the  space  envi¬ 
ronment,  spacecraft  are  deployed  without  an  inherent  ability  to  correct  design 
mistakes,  modify,  or  upgrade  on-board  systems,  or  repair  damaged  components. 
Presently  there  is  no  way  to  upgrade  “multibillion-dollar  satellite  constellations 
with  new  faster  computers  except  to  launch  new  satellites”  [1].  The  long  design- 
to-launch  time  and  subsequent  orbital  lifetime  of  a  satellite  result  in  systems  that 
become  outdated  or  non-productive  due  to  rapid  technology  advancements  after 
design  has  been  finalized.  In  fact,  the  development  cycle  cannot  keep  pace  with 
Moore’s  Law  [2],  forcing  engineers,  even  under  optimal  circumstances,  to  deliver 
hardware  that  is  already  outdated. 

Spacecraft  engineers  must  seek  alternatives  in  their  designs  in  order  to 
satisfy  customer  demands  for  improved  performance  while  ensuring  that  their 
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systems  are  not  vulnerable  to  the  ravishment  of  the  space  environment.  It  is  be¬ 
cause  the  space  environment  tends  to  induce  errors  and  failures  in  electronic  de¬ 
vices,  that  engineers  are  willing  to  trade  performance  for  reliability  and  use  radia¬ 
tion-hardened  parts.  In  order  to  use  commercial-off-the-shelf  (COTS)  devices  in 
lieu  of  radiation-hardened  devices,  and  thereby  provide  state-of-the-art  perform¬ 
ance,  designers  increase  the  risk  of  system  failure  or  malfunction  even  with  the 
use  of  various  fault  avoidance  schemes.  While  using  COTS  devices  may  meet 
performance,  cost,  and  design-to-launch  time  needs,  it  does  not  necessarily  sat¬ 
isfy  the  critical  reliability  or  technology  upgrade  issues.  As  suggested,  however, 
there  exists  several  hardware  and  software  methods  to  improve  (but  not  elimi¬ 
nate)  the  reliability  of  COTS  devices,  with  an  associated  performance  penalty. 

Programmable  logic  represents  a  technology  that  has  the  potential  to 
bridge  the  radiation-hardened  -  performance  gap  because  the  hardware  can  be 
designed  as  a  radiation-hardened  device  while  it  is  programmed  with  a  state-of- 
the-art  functionality.  Static  Random  Access  Memory  (SRAM)  Field  Programma¬ 
ble  Gate  Arrays  (FPGA),  reconfigurable  logic  devices  introduced  in  the  early 
1990’s,  offer  a  possible  solution  to  this  issue.  However,  not  all  of  these  devices 
are  radiation  hardened  and  they  slightly  lag  the  commercial  Application  Specific 
Integrated  Circuit  (ASIC)  performance.  They  nonetheless  offer  numerous  op¬ 
tions  to  the  system  designer  when  considering  the  performance  vs.  reliability 
trade-offs. 

The  focus  of  this  thesis  is  on  the  design,  development,  and  delivery  of  the 
Configurable  Fault  Tolerant  Processor  (CFTP)  flight  hardware.  The  CFTP  is  a 
single  Printed  Circuit  Board  (PCB)  multifunction  system,  maximizing  the  use  of 
COTS  technology  including  FPGAs,  in  order  to  demonstrate  a  reliable,  recon¬ 
figurable  system  capable  of  fully  withstanding  the  deleterious  effects  of  the  space 
environment. 

A.  CFTP  BACKGROUND 

In  order  to  give  this  research  context,  a  brief  discussion  of  the  CFTP  as  an 
orbital  experiment  is  required.  Eager  students,  focused  faculty,  patient  and  gen- 
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erous  sponsors,  as  well  as  valuable  industry  advisers  have  contributed  to  the  de¬ 
velopment  of  this  project.  The  CFTP  represents  much  more  than  the  result  of 
several  theses,  but  also  the  source  for  research  and  discovery  for  years  to  come. 

1.  CFTP  Objective 

The  explicit  objectives  of  the  CFTP  flight  experiment  are  two-fold.  First, 
the  CFTP  will  evaluate  in  various  orbits,  a  Triple  Modular  Redundant  (TMR), 
fault-tolerant,  reconfigurable  System-On-a-Chip  (SOC)  design  in  order  to  mitigate 
bit  errors  in  computation  by  detecting  and  correcting  errors  using  voting  logic. 
Multiple  orbits  are  an  important  aspect  of  the  experiment,  providing  the  opportu¬ 
nity  to  evaluate  the  CFTP  a  variety  of  radiation  fluxes.  Second,  the  CFTP  will 
demonstrate  the  use  of  reprogrammable  FPGA  technology  in  spacecraft  archi¬ 
tecture  as  a  viable  means  of  decreasing  development  time,  decreasing  costs, 
and  increasing  reliability  as  well  as  flexibility  in  hardware  development  and  im¬ 
plementation  [3]. 

2.  Concept 

The  CFTP  design  is  centered  on  the  investigation  of  a  low-cost,  flexible  al¬ 
ternative  for  processor-hardware  architecture,  using  FPGAs  as  a  basis  for  a 
SOC.  The  increased  flexibility  of  the  processor  architecture,  characteristic  of  the 
FPGA,  will  serve  as  a  means  of  decreasing  development  time  while  allowing 
software  development  and  component  integration  to  commence  at  the  earliest 
stages  of  development,  with  the  expectation  that  the  processor  can  be  configured 
to  support  any  design  constraints.  TMR  provides  an  essential  aspect  of  the  reli¬ 
ability  of  the  CFTP  by  mitigating  single  event  transients  in  various  radiation  envi¬ 
ronments.  This  will  enable  the  system  to  continue  its  normal  functional  routine 
without  requiring  a  system  reset  and  commensurate  loss  of  data,  normally  asso¬ 
ciated  with  a  return  to  a  trusted  state.  Finally,  the  flexibility  of  a  configurable 
processor,  based  on  COTS  FPGA  technology,  will  enable  on-orbit  upgrades,  re¬ 
configurations,  and  modifications  to  the  onboard  architecture  in  order  to  support 
dynamic  mission  requirements.  This  processor  reconfiguration  capability  has 
been  previously  unavailable  to  space  systems  engineers  [3].  The  basic  concept 

of  the  CFTP  is  depicted  in  Figure  1 ,  with  the  FPGA-based  TMR  processor  as  the 
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large  block  on  the  left,  the  FPGA’s  configuration  storage  located  at  the  top,  the 
processor’s  memory  on  the  right,  the  host  system  interface  located  at  the  bottom 
(including  transceivers),  and  a  memory  controller  in  the  top  right  all  depicted  on 
PCB  drawing. 


< -  5.3  in  - 

Figure  1 .  CFTP  Conceptual  Diagram 

3.  History 

The  CFTP  has  evolved  considerably  from  its  inception  as  an  investigation 
into  fault-tolerant  computing  techniques  [4].  Research  into  the  applicability,  de¬ 
sign  and  testing  of  component  level  TMR  computers  continued  for  several  years 
and  is  detailed  in  References  [5  -  8].  Concurrently,  the  Naval  Postgraduate 
School  (NPS)  Space  Systems  Academic  Group  (SSAG)  incorporated  a  Config¬ 
urable  Processor  Experiment  (CPE)  into  the  design  of  the  Naval  Postgraduate 
School  Satellite  1  (NPSAT1)  satellite’s  Command  and  Data  Handler  (C&DH). 
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This  experiment,  based  on  findings  from  the  research  referred  to  above,  captures 
the  essence  of  the  present  incarnation  of  the  CFTP.  The  CPE  formally  became 
the  CFTP  in  May  2002  after  briefing  the  CPE  during  the  NPSAT1  Critical  Design 
Review  (CDR).  It  was  at  this  point  when  the  CFTP  became  a  unique  experiment, 
as  opposed  to  a  sub-component  of  NPSAT1  C&DH,  with  the  goal  of  pursuing 
DOD  Space  Test  Program  (STP)  support  in  order  to  integrate  with  additional  sat¬ 
ellites  planned  for  multiple  orbital  regimes.  Through  the  Space  Experiment  Re¬ 
view  Board  (SERB)  process,  the  STP  has  manifested  the  CFTP  on  two  satellites, 
NPSAT1  and  the  United  States  Naval  Academy’s  (USNA)  Midshipmen  Science 
and  Technology  Application  Research  Mission  1  (MidSTAR-1)  satellite.  Re¬ 
search,  design,  and  development  of  the  CFTP  hardware  have  been  on-going 
throughout  the  SERB/STP  process.  Additionally  Lieutenant  Steven  Johnson  de¬ 
veloped  a  TMR  soft-core  microprocessor  for  instantiation  in  the  CFTP’s  SOC  [9], 
based  on  the  research  of  Dr.  Kenneth  Clark  [10].  The  STP  and  SERB  process 
are  detailed  in  Section  C  of  this  Chapter,  and  documentation  from  the  SERB/STP 
process  can  be  found  in  Appendix  A. 

4.  Methodology 

The  methodology  throughout  the  development  of  the  CFTP  has  been  gov¬ 
erned  by  six  rules.  First,  the  CFTP  must  be  reconfigurable.  This  is  to  say  that 
the  CFTP  must  be  able  to  communicate  with  ground  stations,  transfer  data, 
status,  and  instructions,  and  reconfigure  as  commanded.  Second,  the  CFTP 
must  utilize  COTS  technology  whenever  possible  in  order  to  minimize  costs  and 
maximize  performance.  Third,  flexibility  must  be  designed  into  the  hardware. 
Potential  applications  for  the  CFTP  include  spacecraft  control  and  data  handling, 
image  processing  and  compression,  information  and  network  routing,  Digital  Sig¬ 
nal  Processing  (DSP),  and  general  purpose  computing;  as  such,  the  CFTP 
hardware  must  be  designed  to  support  a  myriad  of  applications,  some  of  which 
have  yet  to  be  identified.  Fourth,  the  CFTP  must  be  reliable.  The  components 
selected  and  the  system  design  must  include  necessary  provisions,  either  hard¬ 
ware,  software  or  a  combination,  to  ensure  that  the  system  will  reliably  perform 
its  assigned  task  in  its  prescribed  orbital  environment.  Of  course  there  exists  a 
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practical  bound — the  budget.  The  budget,  as  in  any  space-based  application, 
includes  size,  weight,  and  power,  in  addition  to  the  obvious  cost.  If  any  aspect  of 
the  budget  is  exceeded,  then  CFTP  becomes  in  serious  jeopardy  of  losing  flight 
opportunities.  Sixth,  access  to  multiple  orbits  is  essential  to  the  evaluation  of  the 
CFTP.  Because  higher  orbits  provide  a  much  greater  exposure  to  radiation 
fluxes  and  therefore  an  increased  probability  of  single  event  transients,  these  or¬ 
bits  would  also  supply  a  larger  collection  of  data  with  which  to  evaluate  the  suit¬ 
ability  of  the  design.  Geosynchronous  Transfer  Orbit  (GTO),  Molniya,  or  Medium 
Earth  Orbit  (MEO)  orbits  are  preferred  due  to  high  radiation  environments  en¬ 
countered;  however,  many  of  the  CFTP  design  requirements  can  be  met  with 
high  and  low  inclination  Low  Earth  Orbit  (LEO)  orbits. 

B.  GETTING  TO  SPACE 

The  Space  Test  Program  (STP)  is  a  Department  of  Defense  (DoD)  activity 
under  Air  Force  management  that  provides  space  access  for  DoD  research  and 
development  experiments  [11].  The  STP’s  objective  is  to  obtain  space  flight  for 
experiments  on  the  DoD  SERB  priority  list.  Through  the  SERB,  the  STP  makes  it 
possible  for  DoD  academic  institutions  like  NPS,  United  States  Air  Force  Acad¬ 
emy  (USAFA),  and  USNA,  to  gain  access  to  space. 

1.  STP 

The  STP  was  created  in  1966  by  a  memorandum  from  the  Director  of  De¬ 
fense  Research  and  Engineering  to  provide  space  flight  opportunities  for  all  DoD 
research  and  development  activities  in  an  economic  and  efficient  manner  [12]. 
With  the  primary  objective  of  flying  the  maximum  number  of  payloads  consistent 
with  payload  priority,  launch  opportunities,  and  funding,  the  STP  relies  on  the 
service  level  and  DoD  level  SERBs  heavily.  In  order  for  a  payload  to  be  flown  by 
the  STP,  it  must  first  be  sponsored  by  a  DoD  organization  and  be  screened  by  a 
series  of  review  boards.  The  process  begins  with  submission  of  forms  1721  and 
1721-1,  which  detail  the  nature  of  the  experiment’s  needs.  If  the  experiment  is 
considered  valuable,  then  it  will  be  invited  to  the  appropriate  service’s  SERB  for 
presentation.  Form  the  service  SERB,  the  experiment  is  forwarded  to  the  DoD 

SERB  where  it  competes  for  ranking  against  experiments  from  all  of  the  services. 
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The  outcome  of  the  DoD  SERB  determines  what  the  experiment’s  priority  rank  is. 
Rank,  opportunity,  and  funding  are  the  entering  arguments  from  which  the  STP 
will  create  launch  packages.  This  process  is  shown  in  Figure  2,  and  FY2002 
summary  is  shown  in  Figure  3. 


Figure  2.  STP  Space  Flight  Process  (After  Ref.  [13].) 


Figure  3.  FY2001-FY2002  STP  Summary  (After  Ref.  [13].) 
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2. 


SERB 


As  mentioned  above,  the  SERB  has  two  phases,  consisting  of  a  service 
specific  board  and  a  DoD  board.  Both  boards  rank  experiments  based  on  the 
same  criteria:  military  relevance,  quality  of  experiment,  and  Service  SERB  rank. 

a.  Military  Relevance 

Military  relevance  is  60%  of  the  overall  grade  for  an  experiment.  It 
is  intended  to  ensure  that  the  experiment  does  pertain  directly  to  the  military. 
While  science  experiments  are  allowed,  the  goal  is  to  apply  the  experiment  re¬ 
sults  to  the  war  fighter  in  particular  [9]. 

b.  Quality  of  Experiment 

The  quality  of  the  experiment  is  20%  of  the  overall  grade,  and  it  is 
intended  to  ensure  that  experiments  early  in  their  development,  or  even  still  in  a 
conceptual  phase,  do  not  get  too  great  an  advantage  over  experiments  that  are 
near  completion. 

c.  Service  Priority 

Service  Priority,  also  20%,  takes  into  account  the  previous  two  cri¬ 
teria  and  is  a  numerical  ranking  of  the  experiment  against  the  entire  group  of  ex¬ 
periments  being  presented  that  year.  The  CFTP,  for  example,  was  ranked  13th 
of  24  experiments  at  the  Navy  SERB  in  2002. 

Service  priority  serves  two  purposes.  First,  if  the  experiment  has 
been  presented  in  the  past,  it  is  an  indication  to  the  current  service  and  DoD 
Board  Members  of  the  experiment's  status  the  previous  year.  Second,  it  is  used 
to  prioritize  experiments  at  the  DoD  Board  for  the  service  experiments.  Using  the 
CFTP  as  an  example,  its  ranking  of  13  of  24  placed  it  in  the  middle  of  the  Navy's 
experiments.  This  gave  the  DoD  Board  an  indication  of  the  Navy's  priority  for  the 
experiment.  The  flow  through  the  SERB  process  is  shown  in  Figure  4. 
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Figure  4.  SERB  Process  (After  Ref.  [13].) 


3.  Launch  Vehicle  Integration 

When  the  STP  receives  the  rank  order  list  of  experiments  form  the  SERB, 
it  will  endeavor  to  marry  experiments  to  a  satellite  and  launch  vehicle.  For  some 
experiments,  a  dedicated  platform  is  required,  and  for  others,  such  as  the  CFTP, 
several  satellites  can  fit  into  a  single  launch  vehicle.  The  CFTP,  as  a  single 
printed  circuit  board,  simply  needs  a  card  slot  in  a  satellite,  and  thus  it  was  very 
easy  for  the  STP  to  find  suitable  vehicles  to  carry  this  experiment  to  orbit. 

a.  N PS  ATI 

NPSAT 1  is  an  NPS  experiment  that  was  the  initial  host  of  the  CPE. 
When  the  CFTP  became  a  separate  STP  experiment,  it  required  that  the  integra¬ 
tion  process  between  the  two  in-house  projects  be  formalized.  Fortunately,  from 
a  paperwork  aspect,  the  NPSAT1  design  was  mature  enough  to  forgo  much  of 
the  tedious  early  technical  integration  documentation.  The  result  is  that  the 
CFTP  is  an  integrated  component  of  NPSAT1,  supported  by  the  STP,  and  will  be 
launched  in  March  2006. 

b.  M id  STAR- 1 

The  USNA’s  MidSTAR-1  satellite  provides  a  satellite  “bus”  to  carry 

the  CFTP  and  other  small  experiments  to  orbit.  This  satellite  is  a  SERB  priori- 
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tized  and  STP  integrated  satellite  to  be  launched  in  March  2006,  and  underwent 
the  same  SERB  briefing  schedule  as  CFTP.  While  many  experiments  were 
ranked  higher  than  both  CFTP  and  MidSTAR-1 ,  the  opportunity,  availability,  and 
scale  of  the  projects  were  ideally  suited  for  a  vacancy  on  the  same  launch  vehi¬ 
cle  as  NPSAT1.  Thus,  CFTP  and  MidSTAR-1  commenced  an  aggressive  inte¬ 
gration  schedule  requiring  a  considerable  amount  of  documentation,  to  satisfy 
contractor  and  STP  requirements.  Appendix  A  includes  SERB  and  STP  dcumen- 
tation  that  has  been  required  to  integrate  the  CFTP  in  these  two  satellites. 

C.  PURPOSE 

The  purpose  of  this  research  is  to  design,  develop,  and  deliver  reliable 
CFTP  developmental  and  space  flight  systems  utilizing  COTS  hardware,  maxi¬ 
mizing  flexibility  in  design,  and  guaranteeing  reconfigurability.  This  research 
specifically  concentrates  on  the  component  parts  selection  and  the  PCB  layout 
for  the  CFTP.  The  end  result  of  this  research  will  be  the  CFTP  ready  for  system 
test  and  evaluation  leading  to  program  CDR. 

This  work  will  not  address  the  TMR  microprocessor  soft-core  developed  in 
Reference  [9],  nor  will  it  specifically  address  the  Error  Detection  and  Correction 
(EDAC)  coding  which  will  become  an  integral  part  of  the  data  structure.  These 
topics,  as  well  as  additional  FPGA  configurations  and  system  wide  pre-launch 
test  and  evaluation  are  left  for  future  research. 

D.  ORGANIZATION 

This  thesis  will  detail  the  design  and  development  of  the  first  CFTP  PCB 
and  is  organized  much  like  the  design  process  itself.  Chapter  II  is  a  discussion  of 
the  operating  environment,  the  effects  it  has  on  electronics,  and  methods  to  miti¬ 
gate  those  effects.  Chapter  III  provides  background  material  on  the  technologies 
that  served  as  the  foundation  for  this  design.  Chapter  IV  is  a  discussion  of  the 
hardware-design  trade  space,  processes  that  contributed  to  design  decisions  and 
a  discussion  of  the  development  process.  Chapter  V  discusses  the  parts  se¬ 
lected  for  the  CFTP.  Chapter  VI  presents  the  CFTP  as  a  completed  system.  Fi¬ 
nally,  Chapter  VII  will  offer  concluding  remarks  and  topics  for  follow-on  research. 
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E.  ADDITIONAL  DOCUMENTATION 

Appendix  A  contains  SERB  and  STP  required  documentation,  as  an  es¬ 
sential  aspect  of  the  entire  CFTP  process.  This  documentation  has  served  to  de¬ 
fine  the  scope  of  this  project  throughout  the  development  of  the  CFTP. 

The  detailed  schematic  diagrams  of  the  CFTP  and  CFTP  PCB  layer  dia¬ 
grams  are  presented  in  Appendixes  B  and  C,  respectively.  Finally,  Appendix  D 
contains  a  glossary  of  terms  used  throughout  the  thesis. 
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II.  THE  SPACE  ENVIRONMENT  AND  ITS  EFFECTS 


The  harsh  environment  of  space  exacerbates  common  electrical  circuit  er¬ 
ror  occurrences  seen  on  earth,  as  well  as  introducing  a  new  set  of  problems. 
Close  to  earth’s  surface,  within  the  atmosphere,  circuits  are  shielded  from  many 
of  the  effects  of  space,  most  notably  radiation.  Leaving  the  earth’s  atmosphere, 
a  semiconductor  device  is  exposed  to  an  environment  heavily  populated  by  free 
electrons,  protons,  and  high-energy  ions.  These  particles,  as  well  as  other  as¬ 
pects  of  the  space  environment  can  introduce  a  variety  of  errors  into  logic  cir¬ 
cuits. 

Semiconductor  devices  have  a  well-documented  history  of  susceptibility  to 
the  effects  of  ionized  particles  [14  -  16].  This  radiation  induces  two  principle 
types  of  failures;  Total  Ionizing  Dose  (TID)  effects  and  Single  Event  Effects 
(SEE).  Semiconductor  devices  experience  SEEs  in  the  form  of  Single  Event 
Latchup  (SEL),  Single  Event  Transients  (SET),  and  Single  Event  Upsets  (SEU). 
Potential  solutions  and  methods  to  mitigate  the  effects  of  the  TID  and  SEE  prob¬ 
lems  exist  at  all  levels  of  the  system  design  process,  and  become  a  critical  trade 
space  for  the  systems  engineer  throughout  the  design  process. 

A.  THE  SPACE  ENVIRONMENT 

The  Earth’s  magnetosheath,  ionosphere  and  atmosphere  all  serve  to  pro¬ 
tect  the  surface  environment  from  the  effects  of  the  space  environment.  Beyond 
the  safety  of  our  atmosphere,  there  exists  an  extremely  severe  environment 
characterized  by  all  manner  of  destructive  forces.  The  effects  of  the  conditions  of 
this  environment  have  a  deleterious  effect  on  everything  that  enters  it.  The  con¬ 
ditions  that  will  be  discussed  are  the  effects  of  the  atmosphere  and  gravitation, 
the  effects  of  vacuum  and  debris,  and  radiation  effects. 

1.  Atmospheric  and  Gravitational  Effects 

The  Earth’s  atmosphere  is  far  denser  than  the  space  environment  and 
therefore  requires  vehicles  or  devices  operating  within  the  boundaries  of  our  at¬ 
mosphere  to  be  designed  to  withstand  the  physical  rigors  caused  by  air,  water, 
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trace  elements  and  gravity.  Air,  water,  and  trace  elements  conspire  to  induce 
drag,  as  well  as  to  cause  oxidation  and  erosion  of  materials.  These  lead  to  struc¬ 
tural  weakness  and  must  be  accounted  for  in  the  design  of  any  system  operating 
within  the  limits  of  our  atmosphere.  The  density  and  pressure  of  the  earth’s  at¬ 
mosphere  decrease  exponentially  with  altitude;  nonetheless,  these  effects  can 
still  be  felt  in  LEO  (below  approximately  600  km)  [16].  The  most  significant  ef¬ 
fects  on  a  system,  however,  are  induced  by  the  enormous  forces  associated  with 
overcoming  drag  and  earth’s  gravity  in  order  to  put  a  satellite  or  vehicle  in  orbit. 
The  required  thrust  imposes  enough  stress  on  the  physical  structure  of  a  system 
that  considerable  design  weight  must  be  allocated  to  the  systems’  structural  in¬ 
tegrity. 

2.  Vacuum 

Extending  beyond  Earth’s  atmosphere  effects  (beyond  approximately  960 
km  [16])  is  the  cold  vacuum  of  space.  As  density  and  pressure  decrease,  the  ef¬ 
fects  of  vacuum  become  more  and  more  pronounced.  The  most  significant  ef¬ 
fects  are  outgassing  and  cold  welding.  Outgassing  is  the  release  of  trapped  mo¬ 
lecular  gas  from  any  material  in  a  vacuum.  In  some  cases,  if  the  material  was 
incorrectly  fabricated  or  not  designed  for  use  in  a  vacuum,  the  escaping  gasses 
can  be  have  destructive  effects,  either  directly  due  to  the  loss  of  mass  or  indi¬ 
rectly  due  to  the  deposit  of  the  gas  on  other  surfaces,  called  sputtering  [15,  16]. 
Cold  welding  occurs  when  the  thin  layer  of  molecular  gas  covering  the  surface  of 
a  metal,  which  serves  as  insulation  between  the  metal  and  the  surface  next  to  it, 
is  pulled  away  by  the  vacuum.  The  metals  will  molecularly  bond  together  as  they 
are  now  in  direct  contact,  essentially  welding  the  surfaces  together. 

3.  Debris 

While  celestial  bodies  may  be  few  and  far  between,  there  is  a  significant 
amount  of  debris  in  space.  Particles,  dust,  meteors,  asteroids,  comets,  and 
pieces  of  each  of  the  aforementioned  contribute  to  the  debris  of  space.  In  addi¬ 
tion  to  this  natural  debris,  the  most  common  by-product  of  human  space  explora¬ 
tion  is...  junk.  The  North  American  Aerospace  Defense  Command  (NORAD) 

“tracks  more  then  7000  objects,  baseball  sized  and  larger,  in  earth’s  orbit  [16].” 
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This  debris,  no  matter  how  small,  can  have  catastrophic  effects  on  anything  it 
may  impact  due  to  the  high  speed  it  is  traveling;  in  excess  of  7000  m/s  [16]. 

4.  Radiation 

“Radiation  is  the  movement  of  energy  through  space  by  propagation  of 
waves  or  particles”  [7],  Our  Solar  System’s  radiation  environment  is  dominated 
by  the  Sun;  however,  the  interaction  of  the  Earth’s  magnetic  fields  and  energy  of 
various  forms  from  various  sources  impacting  it  also  have  a  significant  impact  on 
the  near  earth  radiation  environment. 

The  Sun  truly  dominates  the  near  earth  radiation  environment  due  to  its 
proximity  and  extremely  high  energy.  It  is  a  source  of  protons,  heavy  ions  and 
trapped  particles  in  the  Earth’s  magnetosphere  as  well  as  a  modulator  of  Galactic 
Cosmic  Rays  (GCR),  atmospheric  neutrons,  and  trapped  particles  [17],  The  so¬ 
lar  cycle,  an  eleven-year  period  consisting  of  a  seven-year  period  of  solar  maxi¬ 
mum  and  a  four-year  period  of  solar  minimum,  drives  the  type  and  abundance  of 
protons,  electrons,  heavier  ions,  and  GCR’s  that  are  present  in  space  near  earth. 

Solar  particle  events,  including  sunspots  and  solar  flares,  increase  in  both 
number  and  intensity  during  the  solar  maximum.  This  can  have  a  significant  im¬ 
pact  on  communications  and  weather  on  Earth,  even  with  the  natural  shielding 
the  Earth’s  magnetic  field  provides  [17,  18].  Protons  with  energies  up  to  hun¬ 
dreds  of  MeV  and  heavier  ions  with  even  higher  energies  bombard  the  Earth. 

Due  to  its  partially  ionized  nature,  this  matter  has  a  greater  ability  to  penetrate 
the  magnetosphere  than  GCRs  [17], 


Solar  Min 

Solar  Max 

Trapped  Electron  Intensities 

Lower 

Higher 

Trapped  Proton  Intensities 

Higher 

Lower 

Atmospheric  Neutron  Levels 

Higher 

Lower 

Cosmic  Ray  Population 

Peak  Level 

Low  Level 

Table  1.  Electron,  Proton,  GCR  Relative  Intensities  (After  Ref.  [17].) 


15 


Gradual  solar  events,  such  as  coronal  mass  ejections,  are  the  largest  pro¬ 
ton  events.  These  particles  are  accelerated  by  the  shock  wave  created  when  the 
surface  of  the  sun  is  breached  and  the  plume  of  nuclear  material  is  ejected  [17]. 

Solar  wind,  from  the  corona,  streams  off  of  the  Sun  in  all  directions  (not 
uniformly)  at  speeds  of  about  400  km/s  (about  1  million  miles  per  hour).  The  so¬ 
lar  wind  speed  is  high  over  coronal  holes  and  low  over  streamers.  These  high 
and  low  speed  streams  interact  with  each  other  and  alternately  pass  by  the  Earth 
as  the  Sun  rotates  [19].  These  wind-speed  variations  buffet  the  Earth's  magnetic 
field  and  can  produce  magnetic  storms,  ions,  and  an  increase  in  particle  events. 

While  the  Sun’s  effects  on  the  near-earth  radiation  environment  are  the 
most  significant,  there  are  other  contributors  to  the  amount  and  type  of  radiation 
present.  A  GCR  ion  or  a  charged  particle  such  as  Hydrogen,  Helium,  Iron,  etc., 
are  typically  found  in  free  space  and  consequently  are  called  free  space  parti¬ 
cles,  and  have  energy  levels  ranging  from  the  MeV  to  GeV  levels  [17], 

The  net  effect  of  solar  particle  and  GCR  bombardment  on  the  Earth’s 
magnetosphere  is  the  collection  of  protons,  electrons,  and  heavier  ions.  This  col¬ 
lection  of  energized  particles  has  been  previously  referred  to  as  “trapped  parti¬ 
cles.”  These  particles  penetrate  the  Earth’s  magnetosphere  and  collect  in  bands 
around  the  Earth.  These  bands  are  called  the  Van  Allen  Belts  and  are  shown  in 
Figure  5. 


Figure  5.  Van  Allen  Belts  (After  Ref.  [20].) 
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The  trapped  particles  in  the  Van  Allen  Belts  include  electrons  trapped  in 
the  outer  belt  with  energies  up  to  10  MeV,  and  protons  trapped  in  the  inner  belt 
with  energies  from  40  keV  up  to  500  MeV  [20].  The  inner  Van  Allen  Belt  proton 
energies  vary  approximately  inversely  with  altitude.  Figure  6  shows  trapped  par¬ 
ticle  intensities  in  number  per  cm2/s. 
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Figure  6.  Proton  and  Electron  Intensities  (From  Ref.  [17].) 

The  Earth’s  axis  of  rotation  is  not  perpendicular  to  the  sun,  and  a  dip  in  the 
Earth’s  dipole  moment  causes  an  asymmetry  in  the  distribution  of  ions  trapped  in 
the  Earth’s  magnetosphere.  The  sum  of  these  effects  is  the  South  Atlantic 
Anomaly  (SAA),  an  area  where  the  belts  dip  closer  to  the  earth’s  surface.  This 
region  of  concentrated,  unusually  high-energy  protons,  was  documented  by  the 
Multi-angle  Imaging  SpectroRadiometer  (MISR)  instrument  aboard  NASA's  Terra 
spacecraft,  and  is  shown  in  Figure  7. 
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Figure  7.  The  South  Atlantic  Anomaly,  a  Region  of  Extremely  High  Proton 

Density  (From  Ref.  [7].) 


The  above  map  was  created  with  MISR  camera  data  geographically  pro¬ 
jected  over  a  map  of  Earth.  Individual  orbit  tracks  are  visible;  some  are  missing 
due  to  data  gaps,  missing  spacecraft  navigation  information,  or  other  early- 
mission  processing  problems  [21].  The  illuminated  area  shows  a  high  concentra¬ 
tion  of  proton  hits,  depicting  the  higher  radiation  activity  in  the  SAA  . 

The  effects  of  charged  particles  from  GCRs,  solar  particle  events  (solar 
wind,  flares,  coronal  mass  ejections,  etc.),  and  trapped  particles  (the  Van  Allen 
Belts)  have  a  significant  effect  on  a  satellites  and  orbital  vehicles.  Effects  include 
circuit  damage,  sputtering,  surface  damage  due  to  impact,  surface  damage  due 
to  the  charge-discharge  cycle,  leakage,  erosion,  etc.  These  effects  (shown  as 
Hazards),  the  energy  level,  and  the  nature  of  the  source  (shown  as  Environment) 
are  summarized  in  Figure  8  below. 
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Figure  8.  Radiation  Environment  Summary  (From  Ref.  [22].) 

B.  EFFECTS  OF  RADIATION 


In  the  radiation  environment  of  space,  semiconductor  based  circuitry  is 
vulnerable  to  all  of  the  conditions  described  above.  This  section  will  focus  on  the 
effects  of  long-term  exposure  to  radiation  as  well  as  transient  (single  particle 
event)  effects,  as  related  to  semiconductor  devices. 

1.  Total  Ionizing  Dose 

TID  is  the  cumulative  long-term  ionizing  damage  due  to  protons  and  elec¬ 
trons  being  deposited  in  a  device  and  is  measured  in  Radiation  Absorbed  Dose 
(rads).  A  device  that  collects  charged  particles  over  a  long  period  will  eventually 
fail  due  to  the  sum  of  the  radiation  absorbed.  This  failure  point  is  determined  by 
the  material,  physical  design,  and  device  operating  characteristics.  Although 
some  annealing  may  occur  during  periods  of  inactivity  or  reduced  exposure, 
generally  as  TID  increases,  material  degradation  will  increase  until  the  point  of 
failure.  Long-term  exposure  can  cause  device  threshold  shifts,  increased  device 
leakage  and  power  consumption,  timing  changes,  and  decreased  functionality. 
TID  effects  may  be  mitigated  using  radiation-hardened  devices  and  shielding. 
Electrons  and  low  energy  protons  can  also  be  partially  mitigated  with  shielding. 
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Closely  related  to  TID  is  dose  rate,  the  rate  at  which  radiation  accumulates 
in  a  device.  The  dose  rate  classification  of  a  device  specifies  to  what  level  the 
device  was  tested  with  respect  to  rate  of  accumulation  of  radiation.  In  order  to 
clarify  the  relationship  between  TID  and  dose  rate  the  following  brief  example  is 
provided.  A  device  rated  with  total  dose  tolerance  of  100  krad  at  a  dose  rate  of 
10  rad/s  would  indicate  that  it  can  accumulate  up  to  100  krad  of  radiation  before 
failure  at  an  exposure  rate  of  10  rad/s.  Suppose  then  that  this  device  were 
planned  for  use  in  an  orbit  that  averaging  5  krad  accumulation  per  year.  Should 
an  hour-long  solar  event  occur  producing  10  rad/s,  then  36  krad  would  have  ac¬ 
cumulated  in  that  single  hour.  As  a  result,  the  lifetime  of  that  device  would  be 
reduced  approximately  one-third,  or  from  20  years  to  less  then  13  years. 

The  most  significant  radiation-dose  sources  for  satellites  are  from  solar 
energetic  particle  events  (e.g.  solar  flares),  trapped  particles,  and  passage 
through  the  SAA  [23].  In  LEO,  the  principle  dose  source  is  from  the  inner  Van 
Allen  Belt,  and  in  Geostationary  Earth  Orbit  (GEO)  the  outer  Van  Allen  Belt  is  the 
primary  source  of  radiation.  Figure  9  shows  the  ionizing  radiation  environment  in 
space. 


Figure  9.  Ionizing  Environment  (From  Ref.  [23].) 
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2.  Displacement  Damage 

Displacement  Damage  (DD)  is  the  result  of  nuclear  interactions,  typically 
scattering,  which  cause  lattice  defects.  DD  is  due  to  the  cumulative  long-term 
non-ionizing  damage  (as  opposed  to  the  ionizing  effects  with  TID)  from  protons, 
electrons  and  neutrons.  The  collision  between  an  incoming  particle  and  a  lattice 
atom  subsequently  displaces  the  atom  from  its  original  lattice  position  [23].  Fig¬ 
ure  10  shows  this  effect. 
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Figure  10.  Scattering  Effect  of  DD  (From  Ref.  [23].) 


The  particles  that  cause  displacement  damage  include  protons  of  all  ener¬ 
gies,  electrons  with  energies  above  150  keV,  and  neutrons.  Shielding  has  some 
effect  to  mitigate  the  occurrence  of  DD.  DD  degrades  minority  carrier  lifetime;  a 
typical  effect  would  be  degradation  of  gain  and  leakage  current  in  bipolar  transis¬ 
tors.  A  cascade  of  collisions,  shown  in  Figure  1 1 ,  occurs  to  a  portion  of  the 
semiconductor  lattice  atoms.  These  collisions  are  produced  by  both  incident 
“heavy”  particles  (p+,  n',  ions)  and  secondary  particles.  Defects  are  produced 


along  the  tracks  of  secondary  particles  and  in  clusters  at  the  end  of  these  tracks 
[23], 
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Figure  1 1 .  Cascade  and  Clustering  Effects  of  DD  (From  Ref.  [23].) 

3.  Single  Event  Effects 

Simply  stated,  an  SEE  is  any  measurable  effect  to  a  circuit  due  to  an  ion 
strike  [17].  Unlike  the  effects  of  total  radiation  dose,  SEEs  are  instantaneous 
events,  and  are  related  to  the  level  of  radiation  in  a  particular  environment.  An 
SEE  is  caused  by  a  single  charged  particle  as  it  enters  or  passes  through  a 
semiconductor  material  [17].  Heavy  ions  and  protons,  due  to  their  size  and 
mass,  are  significantly  more  likely  to  cause  an  SEE  then  an  electron.  Linear  En¬ 
ergy  Transfer  (LET)  is  a  “measure  of  the  energy  deposited  per  unit  length  as  an 
energetic  particle  travels  through  a  material.  The  common  LET  unit  is 
MeV*cm2/mg  of  material  (e.g.  Si  for  MOS  devices)”  [17].  In  silicon,  for  example, 
if  the  LET  of  the  particle  is  greater  than  the  amount  of  energy  or  critical  charge 
threshold,  an  effect  may  be  seen  [17].  These  effects  are  categorized  as  hard  or 
soft.  Hard  errors  include,  but  are  not  limited  to,  SELs  and  Single  Event  Burnout 
(SEB).  Soft  errors  include  SETs  and  SEUs. 

4.  Single  Event  Latchup 

SEL  is  a  condition  that  may  result  in  the  potentially  permanent  loss  of  de¬ 
vice  functionality  due  to  a  single-event-induced  high-current  state.  Transistors 
are  made  by  layering  silicon  doped  with  impurities,  forming  p-type  and  n-type  re¬ 
gions.  The  arrangement  of  these  p-type  and  n-type  regions  creates  channels  for 
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current  flow  and  is  the  basis  for  transistor  logic.  The  paths  other  than  those  cho¬ 
sen  to  form  the  desired  transistor  can  sometimes  result  in  so  called  parasitic 
transistors,  which  under  normal  conditions  would  not  be  activated.  The  parasitic 
circuit  elements  form  what  are  called  Silicon  Controlled  Rectifiers  (SCR). 

Latchup  occurs  when  a  spurious  current  spike,  such  as  that  produced  by  an  ion 
passing  through  the  device,  activates  an  SCR,  combining  to  make  a  new  circuit 
with  large  positive  feedback.  The  result  is  that  the  circuit  turns  on  and  causes  a 
short  circuit  across  the  device  until  the  device  either  burns  up,  completely  drains 
the  power  supply,  or  the  power  to  it  is  cycled  and  the  parasitic  transistor  is  reset 
[2,  17,  24],  Figure  12  shows  a  normal  Complementary  Metal  Oxide  Semiconduc¬ 
tor  (CMOS)  inverter  and  its  equivalent  circuit  in  the  top  of  the  image,  and  in  the 
bottom  shows  the  parasitic  transistor  that  is  formed  (and  its  equivalent  circuit)  by 
a  charged  particle  entering  the  device. 


Figure  12.  Single  Event  Latchup  (From  Ref.  [24].) 

5.  Single  Event  Transient 

An  SET  is  any  short-duration,  unexpected  change  at  the  output  of  a  com¬ 
binatorial  circuit  caused  by  a  charged  particle  passing  through  a  device.  In  the 
case  of  an  SET  the  event  does  not  damage  the  device  and  only  causes  a  mo¬ 
mentary  “hiccup”  or  short  lived  spike  in  an  output.  The  significance  of  this  type  of 
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event  is  that  the  spike  generated,  although  only  momentary,  may  be  substantial 
enough  to  impact  the  circuit’s  timing.  Figure  13  shows  a  drawing  of  a  notional 
clock  pulse  affected  by  an  SET. 


Figure  13.  Single  Event  Transient.  Double  Clocking  as  a  Result  of  Ion 

Induced  Pulse  (After  Ref.  [25].) 

6.  Single  Event  Upset 

An  SEU  is  any  unwanted  change  of  value  in  a  memory  cell,  which  is 
caused  by  a  charge  absorbed  into  the  device  body  in  a  radioactive  environment. 
More  thoroughly,  an  SEU  is  a  change  of  state  or  transient  induced  by  an  ionizing 
particle  in  a  device.  The  resulting  bit  errors  can  easily  be  corrected  by  resetting 
or  rewriting  the  device,  thereby  returning  it  to  normal  operation  [17].  SEU  errors 
are  classified  as  program  flow  errors,  which  occur  when  any  register  (e.g.,  pro¬ 
gram  counter)  is  affected  by  radiation,  and  data  errors,  which  occur  when  any 
data  storage  (e.g.,  cache)  is  affected  by  radiation.  A  full  SEU  analysis  considers 
the  system  effects  of  an  upset;  for  example,  a  single  bit  flip  while  not  damaging  to 
the  circuitry  involved,  may  damage  the  subsystem  or  system. 

Figure  14  shows  how  an  energetic  particle  can  produce  a  spurious  electri¬ 
cal  signal.  Electron-hole  pairs  are  created  along  the  ion  track  through  the  device. 
The  electrons  and  holes  are  collected  at  the  source  and  drain  of  the  transistor, 
inducing  a  current  pulse  [26].  This  can  be  large  enough  to  produce  an  effect  like 
that  of  a  normal  signal  applied  to  the  transistor. 


24 


Interaction  of  a  Cosmic  Ray  and  Silicon 


/  MOS  Transistor 


Energetic  Charged  particle _ 

Figure  14.  Electron-Hole  Generation  Along  Ion  Path  (From  Ref.  [26].) 

The  circuit  in  Figure  15,  a  simple  one-bit  storage  device,  is  designed  to 
have  two  stable  states,  one  representing  a  stored  'O'  and  one  representing  a 
stored  '1 In  each  state,  two  transistors  are  activated  (on)  and  two  are  deacti¬ 
vated  (off)  [26].  A  bit-flip  (SEU)  may  occur  as  a  result  of  the  current  spike  in¬ 
duced  as  described  above,  causing  the  state  of  the  transistors  in  the  circuit  to  re¬ 
verse.  This  phenomenon  occurs  in  many  circuits,  including  memory  chips  and 
microprocessors,  both  on  earth  and  in  space.  In  a  computer,  a  bit  flip  could  have 
any  number  of  unpredictable  effects,  from  trivial  to  catastrophic. 


Figure  15.  A  Simple  One-Bit  Storage  Device  (From  Ref.  [26].) 
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C.  MITIGATING  THE  EFFECTS  OF  RADIATION 

Numerous  methods,  techniques,  and  work-arounds  exist  to  mitigate  the 
effects  of  radiation  on  a  system.  These  will  be  briefly  discussed  here. 

1.  Fault  Avoidance 

Fault  avoidance  refers  to  a  system  or  device  that  is  designed  to  prevent 
the  occurrences  of  faults.  Each  of  the  below  techniques,  while  reducing  the  like¬ 
lihood  of  a  radiation-induced  failure  by  “building-in”  fault  avoidance,  increases  the 
complexity  of  a  device,  as  well  as  the  cost. 

a.  Shielding 

Shielding  is  the  protecting  of  electronic  circuits  using  materials  im¬ 
penetrable  or  only  partially  penetrable  by  radiation.  It  is  used  at  both  the  device 
level  in  the  form  of  metal  foils  and  chip  packaging,  as  well  as  at  the  system  level 
in  the  form  of  more  substantial  metal  coverings  or  structures. 

(1)  Metal  Foils  and  device  packaging.  Thin,  light-weight 
metal  foils  and  the  shielding  incorporated  into  a  device’s  packaging  add  a  limited 
amount  of  protection  against  radiation.  Most  effective  in  shielding  alpha-particles 
and  low  energy  protons,  thin  metal  tends  not  to  be  effective  for  shielding  GCRs, 
heavy  ions,  gamma  rays,  x-rays,  and  high-energy  trapped  protons  [27]. 

(2)  System  Shielding.  Substantial  shielding,  including  the 
use  of  dense  materials  such  as  lead  can  be  very  effective  at  protecting  the  cir¬ 
cuitry  of  a  space  system.  Unfortunately,  the  weight  of  any  shielding  adds  a  sig¬ 
nificant  burden  to  the  budget,  considering  that  it  costs  “about  $5,000  to  $10,000 
per  pound  to  put  anything  in  space”  [28].  In  some  cases  the  aluminum  walls  of 
the  satellite  may  be  sufficient  [28];  in  others  the  use  of  additional  shielding  must 
considered,  even  though  it  is  essentially  dead  weight.  Consequently,  the  amount 
and  type  of  shielding  to  be  used  must  be  balanced  against  the  mission  profile, 
expected  lifetime,  risk  acceptance,  and  budget. 

b.  Radiation  Hardening 

Radiation  hardening  refers  to  improving  the  tolerance  of  microelec¬ 
tronic  circuits  to  various  types  of  radiation  [29].  The  process,  design  and  layout 
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all  contribute  to  the  level  of  “hardness”  realized  in  a  circuit  or  device.  Radiation- 
hardened  components,  while  not  standardized,  generally  refer  to  parts  that  can 
tolerate  300  krad  or  more  and  are  SEL  immune,  as  opposed  to  radiation-fo/eranf 
devices  which  are  rated  up  to  100  krad  and  do  not  guarantee  SEL  immunity. 

(1)  Process.  The  fabrication  process  is  composed  of 
many  manufacturing  steps  which  can  affect  the  “hardness”  of  the  design.  Silicon 
on  Insulator  (SOI)  provides  for  transistors  to  be  formed  on  top  of  insulating  lay¬ 
ers,  such  as  sapphire,  which  is  less  likely  to  become  charged  by  embedded  ions. 
Similar  to  the  SOI  is  the  use  of  an  epitaxial  (epi)  layer.  This  is  a  lightly  doped 
layer  on  a  heavily  doped  substrate,  which  assists  in  preventing  SCR  formation 
and  the  subsequent  SEL  phenomenon.  Finally,  thin  gate-oxide  designs  tend  to 
provide  more  radiation  tolerance.  The  thinner  gate  oxide  reduces  the  buildup  of 
charged  particles  and  thus  requires  more  charge  before  becoming  biased  leading 
to  an  SEL  [30]. 


(2)  Design.  Designing  radiation  tolerant  circuits  requires 
that  the  organization  and  interconnection  of  electrical  elements,  such  as  resis¬ 
tors,  capacitors,  and  transistors,  be  carefully  considered.  Generally,  larger  ca¬ 
pacitors  will  be  used  for  protection,  thicker  interconnects  will  be  used  in  order  to 
dissipate  more  energy,  and  in  SRAMs  additional  resistors  will  be  used  [27,  30]. 

(3)  Layout.  During  the  layout  process,  guardrings,  or 
channel  stops  [31]  are  used  around  individual  transistors  or  around  areas,  such 
as  high  voltage  circuitry  on  the  device.  Guardrings  are  the  addition  of  p+  and  n' 
diffusion  regions  in  the  p-substrate  or  n-well,  respectively,  and  serve  to  collect 
minority  carriers  injected  into  the  transistor.  By  improving  the  reverse  breakdown 
characteristics  of  the  device,  guardrings  reduce  the  likelihood  of  SELs  [8].  Figure 
16  shows  a  simplified  guardring  concept. 
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Figure  16.  Guardring  (From  Ref.  [32].) 
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2. 


Fault  Tolerance 


The  inability  to  guarantee  fault  avoidance  in  device  and  system  design  re¬ 
quires  that  methods  be  devised  to  reduce  the  impact  of  non-fatal  faults. 
a.  System  Processing  Tolerance 

Numerous  schemes  exist  for  a  system  to  reliably  compute  in  an  er¬ 
ror-prone  environment.  The  use  of  timers,  voters,  and  component  or  module  re¬ 
dundancy  are  the  most  common  methods,  and  are  found  in  both  hardware  and 
software.  Table  2  summarizes  common  protection  methods. 


Protection  Method 

Capability 

Watchdog  Timer 

If  not  reset  within  the  designed  interval* 
perform  some  function  (usually  a  system 
reset). 

Redundancy 

Two  equivalent  systems  operate  on  the  same 
data.  If  the  two  systems  disagree,  a  system 
reset  is  performed. 

Lockstep 

1  Two  devices  in  a  system  are  docked 
simultaneously,  and  which  are  provided 
common  inputs.  If  the  devices  disagree, 
perform  a  system  reset 

Voting 

Use  three  or  more  devices  to  perform  the 
same  function.  If  one  device  disagrees  with 
the  rest,  use  the  remaining  devices  to 
determine  the  next  system  state. 

Repetition 

A  system  must  provide  the  same  data  more 
than  once  to  perform  some  action.  Used,  for 
instance,  to  lower  the  risk  of  an  inadvertent 
spacecraft  command  being  executed. 

Table  2.  Summary  of  Protection  Measures  (From  Ref.  [29].) 

TMR  is  a  combination  of  redundancy  and  voting  as  described  in 
Table  2,  and  can  be  utilized  in  either  hardware  or  software.  With  TMR,  critical 
components  are  replicated.  Each  component  delivers  their  outputs  to  voting 
logic  responsible  for  passing  on  the  corrected  output  in  a  best  two-out-of-three 
manner.  Utilizing  a  scheme  such  as  TMR  provides  the  additional  capability  of 
capturing  data  concerning  the  erroneous  bits  such  as  which  of  the  three  devices 
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it  occurred  in  and  the  time  of  the  error.  The  basic  TMR  concept  is  shown  in  Fig¬ 
ure  17. 


Input  A  — > 

Device  A 

— >  Output  A  — ^ 

Input  B  — ^ 

Device  B 

— >  Output  B  — ^ 

Voting 

Logic 

Input  C  — ^ 

Device  C 

— >  Output  C  — > 

— ^ Voted  Output 


Figure  17.  TMR  Concept  (From  Ref.  [8].) 
b.  Error  Detection  and  Correcting 

It  is  often  impractical  to  use  one  of  the  above  methods  to  mitigate 
the  effects  of  SEEs.  In  fact,  many  systems  both  on  Earth  and  in  space  reduce  or 
eliminate  the  impact  of  errors  through  the  use  of  Error  Detection  and  Correction 
(EDAC)  schemes.  In  addition  to  being  a  necessity  for  certain  systems  such  as 
large  solid  state  recorders  [29],  these  schemes  allow  engineers  to  utilize  emerg¬ 
ing  technologies  while  reducing  much  of  the  associated  risk.  Table  3  summa¬ 
rizes  the  more  common  EDAC  methods. 
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EDAC  Method 

Capability 

Paritv 

Single  bit  error  detect 

Cyclic  Redundancy 
Check 

Any  errors  in  given  structure 

Hamming  Code 

Single  bit  correct,  double  bit  detect 
(most  common);  double  bit  correct 
occasionally  used  (high  overhead) 

Reed- Solomon 

Errors  within  a  symbol,  no  multiple  ; 
errors  within  small  group  of  symbols 

Convolutional 

Encoding 

Corrects  isolated  burst  noise  in  a  data 
stream 

Overlying  protocol 

System  designed  to  correct  data  errors, 
i.e.  bus  data  packet  retransmission  on 
error  detection 

Table  3.  ED  AC  Methods  (From  Ref.  [29].) 

D.  CHAPTER  SUMMARY 

The  severe  environment  found  in  space  wreaks  havoc  on  electronic  de¬ 
vices.  Most  notably,  the  effects  of  radiation  can  cause  a  number  of  device  and 
system  level  failures.  SEE  and  TID  effects  can,  however,  be  mitigated  or  elimi¬ 
nated  through  various  hardware  and  software  technologies. 

This  Chapter  has  defined  the  environment  that  the  CFTP  must  operate  in 
and  is  thus  one  of  the  underlying  reasons  for  design  and  development  decisions 
made  during  the  design  and  develop  process.  Chapter  III  will  provide  additional 
background  information  concerning  the  specific  technologies  researched  as  they 
apply  to  the  CFTP. 
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III.  TECHNOLOGY  BACKGROUND 


The  space  environment,  as  described  in  Chapter  II,  is  a  particularly  inhos¬ 
pitable  place  for  electronic  devices.  The  radiation  of  space  plays  the  most  sig¬ 
nificant  role  in  the  failure  of  electronic  equipment  in  orbit.  There  exists  a  wide 
range  of  these  circuit-crippling  events,  including  total  failure,  SEUs,  SELs,  and 
SETs.  Fortunately,  as  discussed,  there  are  a  number  of  techniques  to  protect 
circuits  from  the  space  environment.  Chapter  II  concluded  with  a  brief  discussion 
of  the  type  of  special  methods  and  procedures  that  must  be  utilized  in  order  to 
mitigate  the  effects  of  radiation.  Unfortunately,  radiation  hardened  devices  which 
are  specifically  designed  to  avoid  faults  or  mitigate  their  effects  have  a  price. 

This  price  is  in  the  form  of  performance,  cost,  and  availability. 

This  Chapter  will  present  a  discussion  of  the  trade-offs  between  COTS 
technology  and  RADHARD  technology  as  background  information  relevant  to  the 
purpose  of  the  CFTP.  Additionally,  this  Chapter  will  introduce  the  key  technology 
that  the  CFTP  is  based  on:  reprogrammable  logic  and  memory. 

A.  COTS  VS.  RADHARD  DEVICES 

The  fault  avoidance  methods  described  in  Chapter  II  are  hardware  meth¬ 
ods  employed  to  harden  a  device  from  the  ravages  of  the  space  environment. 
RADHARD  devices  are  those  designed,  manufactured,  and  packaged  using 
these  and/or  other  techniques,  to  produce  a  device  that  is  guaranteed  to  with¬ 
stand  higher  amounts  of  radiation  than  standard  commercial  devices. 

RADHARD  parts,  due  to  the  exacting  fabrication  requirements  and  the  processes 
involved  to  harden  the  devices  are  by  their  very  nature  slower,  larger,  and  more 
expensive  then  their  commercial  equivalents.  While  the  radiation  tolerance  of 
RADHARD  parts  is  consistently  superior  to  commercial  parts,  RADHARD  as  a 
component  description  is  not  standardized.  For  example,  in  the  FPGA  industry, 
Actel  considers  RADHARD  devices  to  have  SEL  immunity  below  80  LET  and  TID 
tolerant  to  300  krad  [33],  while  Xilinx  considers  its  devices  RADHARD  up  to  125 
LET  and  TID  to  100  krad  [34], 
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In  an  effort  to  clarify,  in  this  document  COTS  components  refer  to  the  lat¬ 
est  developed  technology  such  as  the  Intel  Pentium1  4  3.0  GHz  utilizing  a  0.13 
micron  process  or  the  Sun  UltraSPARC  III2  1.2  GHz,  14-stage  pipelined,  4-way 
superscalar,  variable  instruction  set  microprocessor  utilizing  a  0.15  micron  proc¬ 
ess  [35,  36].  The  focus  of  COTS  technology  is  understandingly  on  the  booming 
and  extremely  lucrative  consumer  market.  By  definition  then,  COTS  devices  are 
not  designed  with  the  features  or  by  the  processes  required  to  harden  them,  and 
are  thus  susceptible  to  TID  effects  and  SEEs.  It  is  sufficient  to  note  that  the  fea¬ 
tures  that  allow  the  COTS  devices  to  perform  so  well  are  features  that  may  lead 
to  radiation  softness.  Thus  COTS  components,  with  few  exceptions,  are  gener¬ 
ally  not  suited  to  operate  reliably  for  long  duration  in  space.  The  exceptions  are 
limited  those  devices  that  were  not  specifically  designed  to  be  radiation  hardened 
but  have  been  extensively  tested  and  found  to  have  radiation  tolerance  of  ac¬ 
ceptable  levels  [8]. 

As  discussed  earlier,  electronic  components  used  in  space  systems  must 
be  radiation  hardened,  very  reliable,  and  available  for  the  long  term.  It  would 
seem  to  make  sense  for  these  reasons  to  utilize  only  RADHARD  parts  for  space 
based  applications.  On  the  other  hand,  due  to  the  long  design-to-orbit  time,  per¬ 
formance,  availability,  and  cost  issues,  RADHARD  parts  may  not  always  be  the 
most  suitable  choice  for  engineers. 

1 .  Design-to-Orbit  Time  and  Performance 

The  length  of  time  from  design  (when  the  parts  are  selected)  to  the  actual 
launch  of  a  satellite  is  excruciatingly  long  as  compared  to  the  time  to  market  for  a 
commercial  system.  This  long  development  time  creates  a  challenge,  as  the  de¬ 
signer  must  accept  technology  that  will  improve  in  performance  as  much  as  two 
or  three  times,  predicted  by  Moore’s  Law  [2],  before  the  system  is  delivered  to 
orbit.  For  example,  the  parts  selected  for  the  CFTP  now  will  not  be  on-orbit  until 
mid-2006;  today’s  technology  will  certainly  be  outdated  by  then.  In  addition  to 
the  technology  leaps  that  occur  after  the  parts  selection  has  been  made,  engi- 

1  Pentium  is  a  registered  trademark  of  Intel  Corporation. 

2  UltraSPARC  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 
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neers  enter  the  design  process  already  behind  current  technology,  considering 
that  the  state  of  the  art  RADHARD  microprocessor  is  the  RAD6000,  a  32-bit  Re¬ 
duced  Instruction  Set  Computer  (RISC)  with  performance  of  35  Megainstructions 
per  second  (MIPS)  running  at  33  MHz,  utilizing  a  0.5  micron  process.  Clearly, 
this  is  hardly  comparable  to  the  performance  of  the  Intel  and  Sun  devices  men¬ 
tioned  above. 

2.  Availability 

The  early  electronics  industry  had  a  natural  focus  on  the  government  and 
military  as  the  primary  customers,  as  the  consumer  market  had  yet  to  develop. 
When  this  held  true,  the  availability  of  radiation  hardened  devices  kept  pace  with 
non-hardened  devices  [8].  Also  contributing  was  that  the  technology  and  fabrica¬ 
tion  process  gap  between  RADHARD  and  commercial  components  was  not  as 
significant  as  it  is  today.  Now,  RADHARD  parts  require  unique  fabrication  lines, 
at  a  cost  of  over  $2  Billion  each  [38].  As  commercial  demand  has  increased,  in¬ 
dustry  has  re-invested  in  the  consumer  electronics  market,  leading  to  a  multipli¬ 
cative  cycle  of  improvement  and  re-investment.  As  a  consequence,  the  low  vol¬ 
ume,  high  risk  RADHARD  market  has  been  left  as  secondary  market  at  best. 
These  factors  all  contribute  to  the  lack  of  available  RADHARD  parts  that  are  now 
made,  with  a  few  exceptions,  as  costly  special  order  parts. 

3.  Cost 

Closely  related  to  the  availability  discussion  above,  is  the  issue  of  cost. 
The  cost  of  commercial  components  is  driven  by  the  demand  of  the  consumer 
market  which  is  far  greater  that  the  demand  of  the  RADHARD  market.  This  de¬ 
mand  has  led  manufacturers  to  focus  on  technology  progress  in  order  to  improve 
sales  and  increase  demand,  while  endeavoring  to  reduce  cost  throughout  the  en¬ 
tire  process.  As  a  result,  state-of-the-art  commercial  parts  are  available  in  large 
volume  at  relatively  low  cost.  Meanwhile,  the  RADHARD  market  did  not  develop 
as  the  commercial  market  did;  as  such,  it  considerably  lags  in  performance  and 
cost.  To  illustrate  this  point,  Actel  retails  their  commercial  A1280  FPGA  for  $433 
while  the  RADHARD  version  RH1280  sells  for  over  $10,000  [39]. 
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4.  Which  Technology  to  Choose? 

One  of  the  underlying  goals  of  the  CFTP  experiment  is  to  utilize  COTS 
technology  to  the  greatest  extent  possible,  while  ensuring  that  the  design  will 
survive  in  the  space  environment.  Commercial  technology  would  provide  for  a 
high  performance  design,  utilizing  the  state-of-the-art  components,  at  a  cost  that 
is  within  the  allotted  budget.  One  of  the  major  problems  with  commercial  proces¬ 
sors,  however,  is  that  they  quickly  become  obsolete  and,  therefore  unavailable, 
as  new  technology  is  developed  [40].  Using  conventional  wisdom,  regardless  of 
whether  COTS  or  RADHARD  technology  is  selected,  the  performance  of  the  de¬ 
sign  will  be  determined  and  fixed  at  the  time  of  design. 

At  this  point  it  is  valuable  to  recall  another  of  the  design  goals  of  the 
CFTP — reconfigurability.  The  ability  to  upgrade,  modify,  or  correct  the  technol¬ 
ogy  of  the  CFTP  while  it  is  on-orbit  will  allow  for  state-of-the-art  functionality  as 
technology  improves.  While  programmable  logic  offers  a  possible  solution  to  the 
quandary  of  which  technology  to  select,  in  that  the  functions  that  it  perform  can 
be  upgraded  by  reprogramming,  it  does  not  circumvent  the  problem  of  out-of- 
date  technology.  Programmable  logic  allows  design  changes  to  accommodate 
new  requirements  and  to  possibly  counteract  age  or  SEE  related  failures  in  satel¬ 
lites. 

B.  PROGRAMMABLE  LOGIC 

A  Programmable  Logic  Device  (PLD),  in  the  most  basic  context,  may  refer 
to  any  number  of  devices  that  can  be  programmed  to  contain  virtually  any  logic 
network  conceivable  [8].  This  is  in  contrast  to  Application  Specific  Integrated  Cir¬ 
cuits  (ASIC),  which  are  custom  designed,  fabricated,  and  packaged  circuits  for  a 
specific  purpose  and  are  not  changeable  once  made.  Included  under  the  general 
umbrella  of  PLDs  are  programmable  ‘memory’  devices  such  as  Read-Only  Mem¬ 
ory  (ROM),  Programmable  ROM  (PROM),  Erasable  PROM  (EPROM),  and  Elec¬ 
trically  EPROM  (EEPROM),  which  will  be  considered  types  of  memory,  as  op¬ 
posed  to  programmable  logic,  for  this  remainder  of  the  thesis. 
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Prior  to  the  advent  of  PLDs,  logic  functions  were  designed  into  Integrated 
Circuits  (ICs)  with  varying  levels  of  complexity.  These  devices  were  permanently 
programmed  and  evolved  from  basic  logic  functions,  such  as  AND,  OR,  NAND, 
and  NOR  gates,  to  Arithmetic  Logic  Units  (ALUs)  then  complex  microprocessors. 
Because  the  logic  functions  are  permanently  designed  into  the  device,  there  is 
little  flexibility  offered  to  a  system  designer  to  correct  errors,  or  change  the  func¬ 
tion,  without  redesigning  and  re-manufacturing  the  device.  If  an  engineer  were 
not  able  to  utilize  existing,  pre-designed  logic  functions,  the  only  recourse  avail¬ 
able  is  to  design  a  custom  circuit.  ASICs,  however,  can  incur  a  cost  of  over  $1 
million  in  Nonrecurring-Engineering  (NRE)  expenses  and  require  considerable 
time  to  design,  troubleshoot,  and  manufacture  [38].  Additionally,  if  a  mistake  is 
made  or  if  a  change  is  required,  the  process  must  be  repeated.  Programmable 
logic  offers  relief  from  the  inflexibility  of  preprogrammed  logic  and  the  costs  as¬ 
sociated  with  ASICs. 

The  heart  of  the  CFTP  is  the  programmable  logic  SOC  core.  The  core 
FPGA  requires  additional  logic  in  order  to  realize  it  full  potential  as  a  reprogram¬ 
mable  system  while  it  is  on-orbit.  Throughout  the  design  process,  trades  were 
made  between  various  types  of  reprogrammable  devices  for  the  various  devices 
that  make  up  the  CFTP.  This  Section  presents  a  brief  introduction  to  customiza¬ 
ble  logic  solutions  for  system  designer,  as  they  apply  to  the  CFTP.  Programma¬ 
ble  Logic  Arrays  (PLAs)  and  Programmable  Array  Logic  (PAL3s)  are  the  simplest 
form  of  the  broader  category  of  PLDs.  As  technology  has  improved,  the  amount 
of  logic  able  to  fit  within  a  single  1C  has  increased.  This  has  led  to  Sequential  (or 
simple)  PLDs  (SPLDs),  which  include  flip-flops  as  well  as  logic  gates,  providing 
even  more  flexibility.  Figure  18,  below,  summarizes  the  differences  between 
these  three  types  of  PLDs. 


3  PAL  is  a  registered  trademark  of  AMD  [41]. 
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Figure  18.  (a)  PAL  (b)  PLA  (c)  SPLD  (After  Ref.  [42].) 


1.  Complex  Programmable  Logic  Devices 

Complex  PLDs  (CPLDs)  represent  the  next  step  in  programmable  logic 
evolution.  The  shrinking  of  transistor  technology  exceeded  the  scalability  of 
PLDs,  thus  making  extremely  large  PLA/PAL  architectures  unmanageable. 
CPLDs  are,  in  their  simplest  context,  an  amalgamation  of  PLDs  on  a  single  chip, 
thus  allowing  1C  manufacturers  to  reasonably  increase  the  capacity  of  PLDs. 
The  set  of  PLDs  are  tied  together  by  a  programmable  interconnection  structure 
allowing  each  of  the  unit  PLDs  to  connect  to  one-another  on  the  chip  as  a  de¬ 
signer  would  connect  them  as  discrete  parts.  While  conceptually  each  CPLD  is 
similar,  manufacturers  utilize  slightly  different  approaches  to  the  CPLD  architec¬ 
ture.  These  differences  are  found  in  the  individual  PLDs,  the  programmable  in¬ 
terconnect  architecture,  and  the  input/output  blocks.  Figure  19  illustrates  the 
CPLD  concept. 


Figure  19.  Conceptual  CPLD  Architecture  (After  Ref.  [41]  [42].) 
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2. 


FPGAS 


FPGAs  follow  CPLDs  in  the  evolution  of  programmable  logic  and  are  truly 
the  current  paragon  of  PLD  sophistication.  While  not  actually  PLDs  as  described 
above,  FPGAs  are  user-programmable  devices  that  perform  the  functions  of 
Large  Scale  Integration  (LSI)  circuitry.  In  contrast  to  CPLDs  previously  dis¬ 
cussed,  FPGAs  are  comprised  of  many  very  small  logic  blocks  “in  a  sea  of  inter¬ 
connects”  [41].  Comparing  Figure  19  to  Figure  20,  this  concept  becomes  clearer. 


=  Programmable  interconnect 

□  =  Programmable  logic  block 

□  =  I/O  pad 


Figure  20.  Conceptual  FPGA  Architecture  (From  Ref.  [41].) 

The  basic  architecture  of  an  FPGA  is  an  array  of  uncommitted  circuit  ele¬ 
ments,  called  logic  blocks,  and  interconnect  resources  [43].  FPGA  configuration, 
as  mentioned,  is  performed  through  programming  by  the  end  user.  Because 
FPGAs  support  very  high  logic  capacity,  this  technology  has  been  responsible  for 
a  major  shift  in  the  way  few-of-a-kind  or  prototype  digital  circuits  are  designed 
[43].  This  section  will  briefly  describe  two  FPGA  technologies  relevant  to  the 
CFTP,  SRAM  based  FPGAs  and  antifuse  based  FPGAs.  Additional,  detailed  in¬ 
formation  on  FPGA  architecture  can  be  found  in  Refs.  [8,  32,  33,  38,  41  -  49,  52, 
54  -  57], 

a.  SRAM  FPGAs 

Devices  that  utilize  programmable  SRAM-controlled  switches  for 

controlling  gate  nodes  of  pass-transistor  switches  and  to  control  the  select  lines 

of  multiplexers  that  drive  logic-block  inputs,  are  called  SRAM  FPGAs  [43].  As  a 

generic  example,  Figure  21  shows  the  connection  of  one  logic  block  (represented 

by  the  AND  gate  in  the  upper  left  corner)  to  another  through  two  pass-transistor 
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switches,  and  then  a  multiplexer,  all  controlled  by  SRAM  cells.  Whether  an 
FPGA  uses  pass-transistors  or  multiplexers  or  both  depends  entirely  on  the 
manufacturer  and  the  specific  product  [43]. 


Figure  21 .  Generic  SRAM-Controlled  Switch  Architecture  (From  Ref.  [43].) 

Xilinx  Virtex4  SRAM  FPGA  products  “feature  a  flexible,  regular  ar¬ 
chitecture  that  comprises  an  array  of  Configurable  Logic  Blocks  (CLBs)  sur¬ 
rounded  by  programmable  Input/Output  Blocks  (lOBs)  all  interconnected  by  a 
rich  hierarchy  of  fast,  versatile  routing  resources”  [44],  The  Virtex  architecture  is 
centered  on  the  CLBs  providing  the  building  blocks  for  logic  functions,  and  lOBs 
providing  the  interface  between  CLBs  and  the  pins  [44].  Figure  22  shows  an 
overview  of  the  Virtex  architecture. 
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Figure  22.  Virtex  Architecture  Overview  (From  Ref.  [44].) 


4  Virtex  is  a  registered  trademark  of  Xilinx  Corporation. 
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(1 )  lOBs.  lOBs  serve  a  number  of  purposes  and  support 
a  wide  variety  of  Input/Output  (I/O)  signaling  standards.  From  Figure  23  it  can  be 
seen  that  the  lOBs  can  be  buffered  inputs  or  outputs,  or  disabled.  The  three 
storage  elements  can  be  edge-triggered  D-type  flip-flops  or  level  sensitive 
latches  [44],  Each  IOB  has  a  clock  signal  shared  by  the  flip-flops  as  well  as  in¬ 
dependent  clock  enable  signals  for  each  [44].  Additionally,  the  lOBs  serve  to 
provide  electrostatic  discharge  protection. 


Figure  23.  Virtex  IOB  detail  (From  Ref.  [44].) 


(2)  CLBs.  CLBs  are  comprised  of  Logic  Cells  (LCs), 
which  include  a  4-input  function  generator  (implemented  as  4-input  Look-Up  Ta¬ 
bles  [LUTs]),  carry  logic,  and  a  storage  element  [44].  Each  CLB  contains  four 
LCs,  organized  into  two  slice  elements,  as  shown  in  Figure  24. 


GOUT  GOUT 


Figure  24.  Virtex  2-Slice  CLB  (From  Ref.  [44].) 
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(3)  Additional  Logic  and  Routing.  The  Xilinx  FPGAs  con¬ 
tain  additional  logic,  including  Block  SelectRam5  memory,  organized  in  columns, 
four  global  clock  input  pins  for  low-skew  clock  distribution,  and  four  Delay-Locked 
Loops  (DLLs)  to  further  reduce  skew  as  well  as  double  or  divide  the  clock  by  1 .5, 
2,  2.5,  3,  4,  5,  8,  or  16.  As  mentioned  earlier,  the  FPGA  is  logic  surrounded  by  a 
sea  of  interconnects,  which  provides  for  local,  global,  and  I/O  routing.  The  ver- 
saRING6  (refer  to  Figure  22)  provides  local  routing  resources  internal  to  slices, 
among  slices,  and  among  the  General  Routing  Matrix  (GRM).  Local  routing  is 
facilitated  by  CLBs  communicating  directly  to  neighboring  CLBs.  Adjacent  to 
each  CLB  is  the  GRM  which  is  a  switch  matrix  providing  horizontal  and  vertical 
routing  for  general  purpose  and  global  connections.  A  local  routing  block  is 
shown  in  Figure  25;  note  that  the  GRM  interconnects  provide  for  global  intercon¬ 
nect  access.  The  built-in  memory,  clocks,  and  robust  interconnect  architecture 
are  the  features  that  truly  make  the  SRAM  FPGA  so  versatile,  providing  the  user 
with  countless  configuration  options. 


To  Adjacent 
GRM 


5  SelectRAM  is  a  registered  trademark  of  Xilinx  Corporation. 

6  VersaRING  is  a  registered  trademark  of  Xilinx  Corporation. 
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b. 


Antifuse  FPGAs 


The  other  type  of  FPGA  technology  to  be  discussed  is  the  antifuse 
programmable  switch.  Antifuses  start  as  open-circuits,  isolated  by  an  insulator, 
and  form  a  low  resistance  link  only  when  programmed.  They  are  suitable  for 
FPGAs  because  they  can  be  built  using  modified  CMOS  technology,  for  example 
Actel’s  Programmable  Low  Impedance  Circuit  Element  (PLICE7)  antifuse  struc¬ 
ture  [32,  43,  45].  Figure  26,  below,  shows  an  antifuse  (on  the  right)  positioned 
between  two  interconnect  wires  (on  the  left).  The  antifuse  physically  consists  of 
three  sandwiched  layers:  the  top  and  bottom  layers  are  conductors,  and  the  mid¬ 
dle  layer  is  an  insulator  [32,  43].  PLICE  uses  Poly-Silicon  and  n+  diffusion  as 
conductors  and  Oxide-Nitride-Oxide  (ONO)  as  an  insulator.  Other  manufactures 
rely  on  metal  for  conductors,  with  amorphous  silicon  as  the  middle  layer  [43]. 
Figure  27  shows  a  photomicrograph  of  an  antifuse. 


Figure  26.  Antifuse  Structure  (After  Refs.  [43]  [45].) 


Figure  27.  Antifuse  Photomicrograph  (From  Ref.  [46].) 
7  PLICE  is  a  registered  trademark  of  Actel  Corporation. 
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It  is  important  to  note  that  this  antifuse  technology  is  not  repro¬ 
grammable.  Once  the  antifuses  have  been  configured,  the  device  remains  fixed. 
This  is  both  one  of  the  benefits  and  one  of  the  drawbacks  of  this  technology.  The 
topic  of  one-time  programmable  vs.  reprogrammable  will  be  discussed  in  Chapter 

IV. 

The  Actel  antifuse  FPGAs  have  three  primary  modules  that  serve 
as  building  blocks  for  their  devices.  These  are  the  I/O  module,  the  logic  module, 
and  routing  module. 

(1)  I/O  Modules.  As  expected,  I/O  modules  provide  the 
interface  between  device  pins  and  the  logic  array.  Similar  to  the  Xilinx  devices, 
I/O  modules  contain  tri-state  buffers,  input  and  output  latches,  and  can  be  con¬ 
figured  for  input  and/or  output.  Figure  28  shows  an  Actel  I/O  module. 


EN 


*  Can  be  configured  as  a  Latch  or  D  Flip-Flop 
(Using  C-Module) 

Figure  28.  Actel  I/O  Module  (From  Ref.  [45].) 

(2)  Logic  Modules.  Actel  antifuse  FPGAs  use  Combina¬ 
torial  Modules  (C-Modules,  also  called  C-Cells),  Sequential  Modules  (S-Modules) 
and  Register  Cells  (R-Cells)  as  the  basic  logic  building  blocks.  C-Cells  are  used 
in  all  of  their  devices,  while  the  use  of  S-Modules  and  R-Cells  depends  on  the 
family,  generation,  size,  and  complexity  of  the  device.  In  any  case,  either  S- 
Modules  or  R-Cells  will  be  used  with  the  C-Cells.  C-Cells  provide  basic  combina¬ 
torial  functions  and  are  shown  in  Figure  29. 
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Figure  29.  Actel  C-Cell  (From  Re.  [48].) 

S-Modules  provide  sequential  logic  functions  in  the  RH1280 
family  of  devices.  This  module  implements  the  same  combinatorial  logic  found  in 
the  C-Module  with  an  added  sequential  element  at  the  output.  The  sequential 
element  can  be  configured  as  either  a  D-type  flip-flop,  as  a  transparent  latch,  or 
simply  bypassed  [45].  R-Cells  are  found  in  the  majority  of  the  larger,  newer  Actel 
antifuse  FPGAs  and  are  very  similar  to  S-modules.  R-cells  include  a  flip-flop  and 
have  programmable  clock  polarity  selectable  on  a  register-by-register  basis  [48]. 
An  R-Cell  is  shown  in  Figure  30. 
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(3)  Routing.  The  majority  of  Actel  antifuse  FPGAs  cluster 

C-Cells  with  R-Cells  and  then  form  supercluster  from  those.  Depending  on  the 

family  and  generation  of  Actel  device,  these  superclusters  are  linked  using  a 
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combination  of  hardwired  interconnects,  programmable  paths,  and  direct  cell-to- 
cell  transfers  [47  -  49].  Interconnects  for  the  Actel  SX-A  Family  are  shown  in 
Figure  31.  Actel  RADHARD  devices  use  a  slightly  different  and  more  direct  ap¬ 
proach  of  horizontal  and  vertical  metal  routing  tracks  to  connect  logic  and  I/O 
modules.  These  tracks  can  run  the  entire  length  of  the  device  or  they  can  be 
broken  into  segments.  Figure  32  shows  the  RH 1020/1 280  family  interconnect 
structure. 


DirectConnect 
•  No  antifuses 

•0.1  ns  maximum  routing  delay 


FastConnect 

•  One  antifuse 

•  0.3  ns  maximum  routing  delay 


Routing  Segments 

•  Typically  2  antifuses 

•  Max.  5  antifuses 


Figure  31 .  Actel  SX-A  Interconnect  Structure  (After  Ref.  [48].) 
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Figure  32.  Actel  RH1020/1280  Interconnect  Structure  (After  Refs.  [32]  [45].) 


C.  MEMORY 


There  are  two  types  of  memory  used  in  digital  design,  Random-Access 
Memory  (RAM)  and  ROM.  This  section  will  very  briefly  define  those  specific 
types  of  memory  that  are  relevant  to  the  CFTP  design  process. 

1.  ROM 


ROM,  as  previously  stated,  is  a  type  of  programmable  logic.  However, 

this  does  not  mean  that  it  is  not,  in  any  of  its  incarnations,  memory.  Quite  the 
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contrary,  ROM  provides  for  non-volatile  storage  of  data  that  the  system  designer 
desires  to  preserve,  which  in  any  context  is  memory.  Of  course,  ROM  is  combi¬ 
natorial  logic  and,  in  the  strictest  sense  of  the  word,  is  not  a  memory  due  to  the 
lack  of  sequential  component  [41].  Nonetheless,  ROM  will  be  treated  as  memory 
throughout  this  thesis. 

ROM,  by  definition,  can  only  be  read  from,  implying  that  the  device  is  only 
programmed  once,  which  is  in  fact  the  case.  Binary  information  that  is  stored 
within  a  PLD  is  specified  in  some  fashion  and  then  written  into  hardware  [42]. 

This  is  the  process  of  programming  a  ROM.  The  information  that  is  stored  in  the 
ROM  can  be  read  when  called  on,  but  not  written  to  or  altered.  Similar  to  the 
evolution  of  the  PLDs  discussed  earlier,  ROM  has  also  evolved  through  a  num¬ 
ber  of  programmable  versions. 

a.  PROM 

PROM  is  similar  to  ROM,  in  that  it  can  only  be  programmed  once, 
except  the  customer  may  program  the  PROM  using  relatively  inexpensive 
equipment.  This  is  as  opposed  to  the  extremely  costly  (in  terms  of  NRE)  manu¬ 
facturer’s  mask-programming  process  used  to  program  ROM.  Using  a  PROM 
programmer  the  customer  can  store  data  of  his  choosing  (program  the  PROM) 
by  vaporizing  fuzable  links  inside  of  the  device,  and  thus  permanently  establish¬ 
ing  a  logic  value. 

b.  EPROM 

Following  PROMs  were  EPROMs,  which  use  floating-gate  Metal- 
Oxide  Semiconductor  (MOS)  technology,  rather  than  bipolar  ICs.  Because  of 
this  technology  shift,  EPROMs  can  be  erased,  or  reset,  to  their  initial  state  by  ex¬ 
posure  to  ultraviolet  light.  While  EPROMS  can  be  extremely  difficult  to  program 
in  situ,  they  nonetheless  offer  greater  flexibility  to  circuit  designers. 

c.  EEPROM/ FLASH 

EEPROM  provides  the  greatest  degree  of  flexibility  for  the  system 
designer.  EEPROM  can  be  electrically  erased,  instead  of  by  ultraviolet  light,  and 
then  reprogrammed,  all  in  situ.  EEPROMS,  due  to  their  thin  insulating  layer,  can 
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be  worn  out  with  repeated  erasing  and  re-writing,  thus  limiting  the  number  of 
times  it  can  be  written.  EEPROMS  are  typically  used  for  information  that  needs 
to  be  saved  (stored)  when  the  system  has  no  power,  and  that  does  not  need  to 
be  changed  frequently,  such  as  for  an  FPGA  configuration  memory.  EEPROM, 
because  it  can  be  reprogrammed  in  a  ‘flash’  are  often  called  flash  memories  [41] 
Table  4  summarizes  the  ROM  types  discussed. 


Tvnp 

Terhnnlnnv 

Read  Hvrlp 

Write  Hvrle 

nnmmentQ 

Mask  ROM 

NMOS/CMOS 

10-200  ns 

4  weeks 

Write  once;  low  power 

Mask  ROM 

Bipolar 

<  100  ns 

4  weeks 

Write  once;  high  power;  low  density 

PROM 

Bipolar 

<  100  ns 

1 0-50  jis/byte 

Write  once;  high  power;  no  mask  change 

EPROM 

NMOS/CMOS 

25-200  ns 

1 0-50  ps/byte 

Reusable;  low  power;  no  mask  change 

EEPROM 

NMOS 

50-200  ns 

1 0-50  ps/byte 

10,000-100,000  writes/location  limit 

Table  4.  Summary  of  ROM  Types  (From  Ref.  [41].) 


2.  RAM 

RAM,  simply  stated,  accepts  new  information,  stores  it,  and  presents  it  for 
use  when  requested  [42].  This  is  the  type  of  memory  that  is  most  often  associ¬ 
ated  with  computers.  RAM,  unlike  ROM,  includes  sequential  logic  and  is  truly  a 
memory  and  provides  for  writing,  as  well  as  reading  the  memory.  The  term  ‘ran¬ 
dom-access’  indicates  that  the  time  required  to  read  or  write  a  bit  of  memory  is 
independent  of  the  location  (address)  in  the  RAM.  The  most  common  types 
RAM  are  briefly  described  here. 

a.  Static  RAM  (SRAM) 

In  an  SRAM,  data  stored  in  a  location  will  remain  unchanged  as 
long  as  power  is  not  removed  from  the  device,  or  that  the  storage  location  is 
overwritten.  SRAM  uses  multiple  transistors,  typically  four  to  six,  and  no  capaci¬ 
tors  for  each  memory  cell  which  can  require  large  amounts  of  power.  Because  of 
SRAMs  simplicity,  it  offers  short  read  and  write  cycles  and  it  is  easy  to  control. 

b.  Dynamic  RAM  (DRAM) 

In  a  DRAM,  stored  data  must  be  refreshed  periodically  by  reading 
the  data  then  re-writing  the  data  back  to  the  address  it  came  from.  This  is  be- 
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cause  DRAM  memory  cells  are  a  paired  transistor  and  capacitor,  which  tends  to 
‘leak’,  thereby  forgetting  what  is  stored.  The  most  significant  benefit  of  DRAM 
over  SRAM  is  that  it  uses  one  transistor  per  cell,  therefore  much  higher  density 
memory  can  be  produced.  Also,  fewer  transistors  translates  to  lower  power  re¬ 
quired  to  operate  DRAM.  The  primary  and  significant  drawback  is  the  additional 
complexity  of  the  memory  controller  that  must  control  the  refreshing,  as  well  as 
timing  synchronization  for  read,  right,  and  refresh  cycles. 

c.  Synchronous  Dynamic  RAM  (SDRAM) 

SDRAM  builds  upon  the  shortcomings  of  DRAM,  by  making  the 
clocking  more  sensible.  SDRAM  delivers  row  and  column  addresses  in  two 
steps  as  with  DRAM;  however  SDRAM  control  and  address  signals  are  sampled 
only  on  the  rising  edge  of  the  clock,  whereas  DRAM  utilized  both  rising  and  fal¬ 
ling  edges  of  the  clock.  SDRAM  also  takes  advantage  of  a  burst  mode  in  order 
to  improve  performance.  In  this  mode,  the  SDRAM  will  stay  on  the  address  row 
containing  the  requested  bit  and  read  column  data  under  the  assumption  that 
data  is  generally  stored  sequentially.  The  logic  required  to  control  SDRAM  is  on 
par  with  that  of  DRAM,  although  SDRAM  is  much  faster. 

D.  CHAPTER  SUMMARY 

This  Chapter  served  to  provide  background  information  relevant  to  the  de¬ 
sign  process  of  the  CFTP.  Fundamental  to  the  design  goals  for  the  CFTP  are 
the  concepts  of  designing  a  system  that  is  reconfigurable,  maximizing  the  use  of 
COTS  technology,  while  ensuring  that  the  components  will  not  fail  due  to  the  per¬ 
ils  of  the  operating  environment. 

Chapter  IV  will  explore  design  considerations  and  constraints  for  the  de¬ 
velopment  of  CFTP.  These  considerations  and  constraints  include  such  things 
as  interface  requirements,  power  constraints,  and  PCB  layout  considerations. 

The  Chapter  will  conclude  with  an  overview  of  the  CFTP’s  design. 
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IV.  HARDWARE  DESIGN  TRADE  SPACE 


The  technologies  discussed  in  Chapter  III  provide  contextual  background 
for  a  discussion  of  the  evolution  of  the  CFTP  and  the  associated  engineering 
trade  space.  The  design  of  a  sophisticated  electronic  system  has,  in  this  case, 
been  a  very  convoluted  process.  This  process  has  been  aggravated  by  several 
factors  including  the  transient  nature  of  military  graduate  students,  the  support 
available  from  industry,  and  the  educational  process  itself.  Throughout  the  evo¬ 
lution  of  the  CFTP,  it  has  been  clear  the  design  process  has  not  been  linear  in 
nature;  rather  it  has  been  a  feedback  oriented  iterative  process.  Each  subse¬ 
quent  iteration  has  moved  the  system  closer  toward  a  completed  design  for 
space  applications,  while  solidifying  the  objectives  for  the  flight  experiment. 

Over  the  course  of  the  CFTP’s  development,  the  design  framework  has 
evolved.  Constraints  and  considerations  have  grown  as  the  project  developed 
from  its  early  beginnings,  while  the  CFTP’s  flight  design  has  come  to  fruition.  In 
order  to  give  the  discussion  of  the  actual  parts  selected  and  the  physical  layout  of 
the  board,  the  design  trade  space  must  be  considered. 

A.  CONSTRAINTS  AND  CONSIDERATIONS 

The  current  version  of  the  CFTP  is  the  result  of  years  of  NPS  research, 
detailed  in  References  [5  -  10].  As  alluded  to  in  Chapter  I,  the  research  reported 
in  this  thesis  commenced  prior  to  the  NPSAT1  CDR.  This  section  will  describe 
the  state  of  the  CFTP  at  the  start  of  this  research  followed  by  a  brief  discussion 
of  the  design  constraints  established  earlier  in  the  design  process. 

1.  Entering  Arguments 

Considering  that  this  research  is  essentially  the  continuation  of  research 
commenced  several  years  ago,  it  is  reasonable  to  assume  that  a  certain  design 
framework  had  been  established.  It  will  be  shown  through  the  course  of  this  the¬ 
sis  that  some  of  these  initial  conditions  were  inflexible  constraints,  and  others 
were  merely  design  considerations  for  convenience. 
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a.  Design  Framework 

The  initial  design  framework  centered  on  a  TMR  SOC  design  utiliz¬ 
ing  an  FPGA  as  the  centerpiece  of  the  system.  The  initial  processor  to  be  tripli¬ 
cated  for  instantiation  in  the  FPGA  was  developed  by  Dr.  Kenneth  Clark,  and  is 
described  in  detail  in  References  [9]  and  [10].  The  goal  was,  and  remains,  to  de¬ 
sign  a  flexible  system  that  can  be  reconfigured  while  on  orbit  to  perform  a  myriad 
of  functions,  from  general-purpose  processing  to  sophisticated  DSP  algorithms. 
The  hardware  concepts  for  TMR  had  been  explored  and  developed  in  Refer¬ 
ences  [4  -  7],  but  not  until  Lieutenant  Peter  LaShomb’s  thesis  [8]  did  the  pros¬ 
pect  of  using  an  FPGA  become  an  design  alternative.  Thus  the  concept  was  de¬ 
fined  for  the  CFTP:  a  low  power,  fault  tolerant,  reconfigurable,  TMR  SOC,  maxi¬ 
mizing  the  use  of  COTS  technology,  in  order  to  reduce  design  time  and  cost. 

The  initial  concept  is  shown  in  Figure  33  (a),  which  simplistically  displays  the 
concept  of  instantiating  the  TMR  microprocessors  in  an  FPGA.  Figure  33  (b) 
shows  the  next  iteration  of  the  design,  with  a  more  reasonable  memory  configu¬ 
ration. 


(a)  (b) 

Figure  33.  (a)  TMR  Instantiation  Concept  (b)  Early  System  Concept. 
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From  Figure  33,  it  should  be  clear  that  the  concept  of  replacing  the 
previously  researched  and  developed  hardware  based  TMR  design  with  an 
FPGA  based  SOC  architecture  would  be  a  challenge. 

At  the  time  the  FPGA  concept  was  taking  shape,  the  CPE  was  be¬ 
ing  designed  into  NPSAT 1 .  It  was  at  the  CDR,  when  the  NPSAT 1  design  was  to 
be  finalized,  that  the  CPE  became  a  new,  unique  experiment.  While  the  CPE, 
called  CFTP  from  this  point  in  time  forward,  was  just  initiating  the  re-design  proc¬ 
ess  based  on  the  FPGA  SOC  concept,  NPSATI’s  design  timeline  was  fully  ma¬ 
ture.  Because  NPSATI’s  architecture,  power  budget,  interface  requirements, 
mass  budget  and  structural  requirements  were  all  but  finalized,  the  CFTP,  as  an 
integrated  NPSAT1  experiment,  would  be  held  to  the  design  envelope  specified 
at  the  time  when  the  CPE  was  the  planned  experiment. 

(1 )  Size  and  Mass.  Because  the  CPE  was  to  be  included 
in  the  C&DH  case  of  NPSAT  1 ,  it  was  to  be  designed  as  a  single  PCB  with  di¬ 
mensions  of  4.7  inches  by  6.7  inches,  and  it  would  weigh  approximately  1  kilo¬ 
gram.  As  it  has  turned  out,  these  requirements  changed  slightly  in  order  to  ac¬ 
commodate  the  final,  constructed  version  of  the  C&DH  housing.  Figure  34  de¬ 
picts  the  current  CFTP  PCB  dimensions  of  5.3  inches  by  7.3  inches. 


51 


Figure  34.  CFTP  PCB  Dimensions 

(2)  Interface.  NPSAT1  C&DH  was  designed  from  the  on¬ 
set  to  be  based  on  the  PC/104  standard  [50].  While  the  PC/104  standard  de¬ 
scribes  bus  interface  and  communications  between  devices,  it  also  standardizes 
size  and  shape  of  PCBs  [51].  NPSAT1  designers  are  utilizing  the  connector  in¬ 
terface  and  a  majority  of  the  signal  assignments;  however  the  physical  dimen¬ 
sions  of  the  PCB  are  larger  than  the  PC/104  standard.  As  a  result,  the  CFTP  is 
constrained  to  utilize  the  16-bit  PC/104  bus  interface  and  the  signaling  bus  sig¬ 
nals  specified  by  the  NPSAT1  architects,  which  will  be  specifically  identified  in 

Chapter  VI.  Figure  35  shows  the  16-bit  PC/104  interface. 
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Figure  35.  16-bit  PC/104  Connector  (After  Ref.  [51].) 


(3)  Power  budget.  When  conceived,  one  of  the  experi¬ 
mental  objectives  was  to  deliver  a  low  power  system.  This  objective,  in  conjunc¬ 
tion  with  the  CPE  being  considered  an  opportune,  small-scale  experiment  for 
NPSAT1,  led  to  the  limited  power  budget  of  4  Watts,  nominal.  Additionally,  the 
NPSAT1  team  planned  for  a  25  percent  duty  cycle,  expecting  the  CPE  to  draw 
an  average  of  1  Watt  [50].  This  has  become  a  serious  constraint,  as  the  CFTP 
goals  include  continuous  operation  in  an  effort  to  catalog  SEU  information,  in¬ 
cluding  location  of  satellite  at  time  of  fault,  type  of  fault,  fault  location  (within  the 
processor),  and  fault  recovery  time.  Unfortunately,  the  nature  of  FPGAs  do  not 
provide  for  convenient  power  estimation.  This  is  because  each  of  the  nearly  infi¬ 
nite  configurations  has  a  unique  power  profile,  and  thus  can  not  be  predicted  by 
the  manufacturer.  The  end  result  is  that  the  NPSAT1  team  had  enough  flexibility 
in  the  power  budget  to  allow  the  CFTP  to  target  5  Watts  for  normal  operation  with 
usage  peaks  potentially  as  high  as  10  Watts.  Should  the  CFTP  exceed  the 
power  budgeted,  then  a  duty  cycle  will  be  imposed. 

b.  Components 

At  the  commencement  of  this  research,  the  CFTP  design  included 
two  central  devices,  while  the  remainder  of  the  design  was  a  tabula  rasa.  The 
legacy  components  were  SRAM  and  an  FPGA.  SRAM  provided  the  CPE’s  prin¬ 
ciple  memory  for  the  simple  reason  that  it  is  the  memory  used  in  NPSAT 1  ’s 
C&DH.  The  most  significant  advantage  of  using  this  memory  would  be  the  sav¬ 
ings  in  design  time  related  to  the  memory  controller  and  the  EDAC  or  Error  Cor¬ 
rection  Circuitry  (ECC).  Because  this  hardware  had  flown  on  NPS’s  Petit  Ama¬ 
teur  Naval  Satellite  (PANSAT),  the  base  coding  was  already  complete.  Despite 
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the  convenience  using  of  this  memory  offers,  it  has  since  been  replaced  in  the 
CFTP  design,  is  detailed  in  Chapter  V. 

The  other  component  included  as  a  conceptual  starting  place  was  a 
Xilinx  Virtex  FPGA.  The  use  of  an  FPGA  as  the  core  technology  for  the  SOC  has 
been  mentioned  frequently  throughout  this  thesis.  The  reasoning  behind  the  se¬ 
lection  of  the  Virtex  device  as  the  centerpiece  of  the  CFTP  is  explained  in  detail 
in  Reference  [8]  and  will  be  touched  upon  in  Chapter  V  of  this  thesis.  Section  B 
of  this  Chapter  will  describe  the  trade  space  when  considering  the  use  of  FPGAs. 

2.  CFTP  Goals 

The  goal  of  the  CFTP  as  a  program  has  remained  consistent  over  the 
years  and  across  graduate  researchers.  While  specific  theses  have  sought  to 
solve  unique  research  questions,  the  sum  of  the  body  of  works  has  remained 
true  to  the  basic  goal  of  designing  a  reliable,  reconfigurable,  low-power,  low-cost 
flexible  system  for  space  applications.  It  is  critical  that  the  design  and  develop¬ 
ment  of  the  CFTP,  represented  by  this  thesis,  remain  true  to  the  goal  of  the  pro¬ 
gram  as  a  whole.  As  such,  the  goals  of  the  CFTP  project  are  the  most  rigorous 
constraints  applied  on  the  design  process,  and  are  what  will  ensure  its  future  role 
as  an  experimental  test  bed  for  multiple  on  orbit  projects. 

B.  FPGA  DESIGN  CONSIDERATIONS 

The  use  of  an  FPGA  as  the  focus  of  the  CFTP  is  a  forgone  conclusion  at 
this  point.  However,  this  does  not  invalidate  a  further  refinement  of  the  actual 
part  selected.  The  decision  to  use  a  particular  part  from  a  particular  manufac¬ 
turer  is  based  on  a  multitude  of  factors.  This  section  is  provided  in  an  effort  to 
define  the  trade  space  available  to  a  system  engineer. 

1.  Gate  Count 

Gate  count  is  an  FPGA  industry  metric  that  roughly  corresponds  to  the 
number  of  logic  gates  that  can  be  implemented  in  an  FPGA.  This  metric,  how¬ 
ever,  can  be  misleading.  Are  the  logic  blocks  two-input  AND  gates,  or  four-input 
XOR  gates?  Perhaps  more  useful  indicators  of  usable  logic  are,  for  example,  the 
number  of  CLBs  and  LUTs  in  Xilinx  devices  and  C-Cells  and  R-Cells  in  Actel  de- 
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vices.  Typical  of  the  technology  industry,  these  more  meaningful  indicators  rep¬ 
resent  multiple,  uncorrelated  standards,  which  can  make  a  direct  comparison  dif¬ 
ficult.  As  a  result,  gate  count  remains  the  predominant  size  comparison  index. 
Shown  in  Tables  5  and  6  are  examples  of  proprietary  gate  count  tables  from  Xil- 
inx  and  Actel,  respectively.  Note  that  the  number  of  programmable  assets  avail¬ 
able  in  these  FPGAs,  while  not  their  top-of-the-line  devices,  is  quite  substantial. 


Device 

System  Gates 

CLB  Array 

Logic  Cells 

Maximum 
Available  I/O 

Block  RAM  Bits 

Max  Select 
RAM  Bits 

XQVR300 

322,970 

32x48 

6,912 

316 

65,536 

98,304 

XQVR600 

661,111 

48x72 

15,552 

316 

98,304 

221,184 

XQVR1000 

1,124,022 

64x96 

27,648 

404 

131,072 

393,216 

Table  5.  Xilinx  RADHARD  FPGA  Gate  Counts  (From  Ref.  [34].) 


Device 

RH1020 

RH12S0 

Capacity 

System  Gates 

3,000 

12,000 

Gate  Array  Equivalent  Gates 

2,000 

8.000 

PLD  Equivalent  Gates 

6,000 

20,000 

TTL  Equivalent  Packages 

50 

200 

20-Pin  PAL  Equivalent  Packages 

20 

80 

Logic  Modules 

547 

1 ,232 

S-  Modules 

0 

624 

C- Modules 

547 

608 

Flip-Flops  (Maximum) 

273 

998 

Routing  Resources 

Horizontal  Tra ck s / Cha in nell 

22 

35 

Vertical  Tracks/ Channel 

13 

15 

PLICE  Antifuse  Elements 

186,000 

750,000 

User  I/Os  (Maximum) 

69 

140 

Packages  (by  Pin  Count) 

Ceramic  Quad  Flat  Pack  (CQFP) 

84 

172 

Table  6.  Actel  RADHARD  FPGA  Gate  Counts  (From  Ref.  [45].) 

2.  Packages 

Figure  36  shows  a  sampling  of  the  types  of  FPGA  packages  available  to 
the  system  designer.  Due  the  enormous  amount  of  programmable  logic  avail¬ 
able  in  FPGAs,  a  large  number  of  I/O  pins  are  required  to  perform  today’s  de¬ 
manding  applications.  For  example,  the  FG1 152  package  shown  in  Figure  39 
has  1152  pins!  While  this  may  seem  excessive,  designers  often  find  that  they 
run  out  of  I/O  pins  and  must  limit  their  designs.  The  type  of  package  plays  an 
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important  role  in  device  selection,  not  only  because  of  the  number  of  I/O  pins,  but 
for  other  reasons  as  well.  Table  7  summarizes  Xilinx  Virtex  family  packages, 
showing  number  of  I/O  pins  and  part  availability. 
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Figure  36.  Example  FPGA  Packages  (From  Ref.  [52].) 
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Package 

XCV50 

XCV100 

XCV150 

XCV200 

XCV300 

XCV400 

XCV600 

XCV800 

XCV1000 

CS144 

94 

94 

TQ144 

98 

98 

PQ240 

166 

166 

166 

166 

166 

HQ240 

166 

166 

166 

BG256 

180 

180 

180 

180 

BG352 

260 

260 

260 

BG432 

316 

316 

316 

316 

BG560 

404 

404 

404 

404 

FG256 

176 

176 

176 

176 

FG456 

260 

284 

312 

FG676 

404 

444 

444 

FG680 

512 

512 

512 

Table  7.  Xilinx  Virtex  Package  and  User  I/O  Pins  (From  Ref.  [44].) 
a.  Ball  Grid  Array  (BGA) 

BGAs,  such  as  on  the  FG1 152,  provide  the  highest  number  and 


density  of  pins  available.  In  addition  to  the  high  pin  count,  BGAs  offer  larger  lead 
pitches,  occupy  less  space  on  the  PCB,  and  dissipate  heat  better.  BGAs,  how¬ 
ever,  are  not  compatible  with  multiple  solder  processing  methods,  and  individual 
solder  joints  cannot  be  inspected  and  reworked  using  conventional  methods.  In 
fact,  any  joint  not  in  the  outer  rings  cannot  be  inspected.  Additional  drawbacks 
are  that  special  techniques  are  required  to  affix  the  device  to  the  PCB  and,  in  or¬ 
der  to  route  the  multitude  of  signals  from  the  pins,  a  multilayered  PCB  is  re¬ 
quired.  Figure  37  shows  several  representative  BGA  profiles. 


Plastic  BGA  (PBGA)  Ceramic  BGA  (CBGA) 


Flip  Chip  BGA  (FCBGA)  Column  CBGA  (CCGA) 


Figure  37.  BGA  Example  Configurations  (From  Ref  [53].) 
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b.  Flat  Pack 

Flat  packs  are  surface-mount  packages  that  provide  physical  ac¬ 
cess  to  all  of  the  pins.  Figure  38  shows  an  example  of  a  208  lead-Quad  Flat 
Pack  (QFP).  The  benefits  of  flat  packs  are  the  drawbacks  of  BGAs,  and  vice 
versa.  For  example,  it  is  obvious  from  Figure  38  that,  while  each  of  the  leads  is 
extremely  thin,  each  can  be  visually  inspected  and  repaired.  This  is  a  critical 
point  for  space  applications.  Without  the  ability  to  inspect  the  contacts,  solder 
joints,  and  pads  before,  during,  and  after  qualification  testing,  there  is  no  way  to 
ensure  that  the  device  will  maintain  sufficient  contact  for  operations.  Conse¬ 
quently,  QFPs,  and  not  BGAs,  are  utilized  in  virtually  all  space-related  applica¬ 
tions. 


Figure  38.  208  Lead  QFP  (From  Ref.  [54].) 

3.  Availability 

As  with  any  part,  availability  is  crucial.  Commercial  FPGAs  command 
over  50%  of  the  programmable  market  and  are  making  ASICs  less  and  less  at¬ 
tractive  [38].  The  result  is  that  manufactures  are  producing  larger  and  larger 
quantities  of  commercial  parts.  Unfortunately,  most  manufactures  are  following 
the  microprocessor  rubric  discussed  in  Chapter  III  and  are  not  developing 
RADHARD  parts.  Consequently,  there  remains  a  parts  availability,  as  well  as 
technology  lag,  in  the  Radiation  Tolerant  markets. 
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In  addition  to  the  availability  of  the  devices,  there  is  an  additional  availabil¬ 
ity  issue — what  to  instantiate  in  these  million-plus  gate  devices.  Intellectual 
Property  (IP)  cores,  also  known  as  ‘soft-cores,’  are  the  Hardware  Description 
Language  (HDL)  code  which  programs  the  FPGA  to  act  the  same  as  a  hardwired 
part  such  as  a  microprocessor.  For  example,  it  is  possible  to  instantiate  an  x86 
soft  core  microprocessor  in  an  FPGA.  The  result  is  the  complete  functionality  of 
that  microprocessor,  with  the  added  benefit  of  being  able  to  reprogram  it  to  be, 
for  example,  a  RISC  processor  the  next  day.  Unfortunately,  the  development  of 
IP  cores  is  exceedingly  time  consuming,  not  to  mention  challenging.  The  result 
is  that  state-of-the-art  microprocessors  are  not  available  in  suitable  code  form  for 
implementation  into  FPGAs. 

4.  Radiation  Tolerance 

Following  the  discussion  in  Chapter  III  regarding  RADHARD  components, 
this  section  will  point  out  only  that  SRAM-based  FPGAs,  unless  special  meas¬ 
ures  are  taken,  are  inherently  radiation  soft.  Antifuse  FPGAs  in  their  commercial 
form  provide  slightly  more  TID  tolerance  than  their  SRAM  counterparts.  The 
leading  manufactures  of  both  of  these  technologies  do  offer  RADHARD  and  Ra¬ 
diation  Tolerant  devices  specifically  for  the  aerospace  industry.  The  special 
techniques  used  by  these  manufactures  include  a  larger  (0.8-|im-1.0-|im)  proc¬ 
esses,  sophisticated  masking  procedures,  and  stringent  test  and  verification 
methods  in  order  to  guarantee  that  the  devices  will  withstand  a  particular  TID 
amount.  Additionally,  the  devices  are  fabricated  on  an  epi  substrate,  providing 
additional  protection  from  SELs.  Although  RADHARD  antifuse  devices  are 
harder  than  SRAM  devices,  the  latter  are  closing  the  gap  rapidly.  While  these 
devices  slightly  lag  the  most  current  technology  (highest  gate  counts  and  fastest 
operating  speeds)  they  do  provide  requisite  protection  for  space  applications. 

5.  Reprogrammability 

Reprogrammability  must  be  considered  when  selecting  a  particular  FPGA 
for  use  in  a  system.  Also,  the  manner  in  which  they  are  reprogrammed  is  an  ad¬ 
ditional  concern.  Consideration  must  be  given  to  in  situ  reprogramming  methods, 

in  addition  to  load  and  read  capabilities.  As  suggested  earlier,  One-Time  Pro- 
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grammable  (OTP)  devices  are  generally  more  radiation  tolerant  than  reprogram¬ 
mable  devices.  Likewise,  reprogrammable  CPLDs  are  generally  more  radiation 
tolerant  but  require  removal  from  the  system  in  order  to  be  reprogrammed  [8]. 
The  ability  to  reconfigure  an  embedded  device,  using  a  simple  set  of  commands, 
certainly  has  advantages  for  space  based  applications. 

a.  Configuration 

The  specific  method  of  reprogramming  a  device  may  also  be  a  fac¬ 
tor  in  device  selection.  When  considering  Xilinx  products,  there  are  four  methods 
available  to  configure  the  Virtex  family:  SelectMAP8,  Master  or  Slave  serial,  and 
JTAG.  The  actual  process  of  loading  an  external  configuration  is  a  matter  of 
loading  the  configuration  bit  stream  into  the  FPGA  using  the  desired  mode.  Ta¬ 
ble  8  is  a  summary  of  configuration  file  sizes  for  Virtex  devices.  The  external 
process  flow  is  shown  in  Figure  39  (a).  Figure  39  (b)  shows  the  processing  flow 
internal  to  the  FPGA  during  configuration. 


Device 

#  of  Configuration  Bits 

XCV50 

559,200 

XCV100 

781,216 

XCV150 

1,040,096 

XCV200 

1,335,840 

XCV300 

1,751,808 

XCV400 

2,546,048 

XCV600 

3,607,968 

XCV800 

4,715,616 

XCV1000 

6,127,744 

Table  8.  Virtex  Bit-Stream  lengths  (From  Ref.  [44].) 


8  SelectMAP  is  a  registered  trademark  of  Xilinx  Corporation. 
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(a) 


(b) 


Maximum  of  three 
CCLK  cycles. 


Define  32-bit  word 
boundaries. 


Initialize  CRC 
calculation. 

Internal  use. 


Set  start-up  and 
ConfigRate. 

Internal  use. 


Master  Serial  CCLK 
changes  to  optional 
configuration. 

Data  frames  written  to 
configuration  memory. 

Start-up  Sequence 
commences  after 
CRC  calculation. 

If  CRC  fails,  start-up  is 
aborted.  Otherwise, 
Start-up  Sequence 
commences. 

FPGA  is  active. 


Figure  39.  (a)  External  Configuration  Process  Flow  (After  Ref.  [57].)  (b)  Inter¬ 

nal  Configuration  Process  Flow  (After  Ref.  [55].) 


(1)  Master/Slave  Serial  Mode.  In  master/slave  mode  of 
configuration,  one  bit  of  configuration  data  is  loaded  at  a  time.  In  the  master 
mode,  the  FPGA  being  configured  drives  the  configuration  clock  and  in  slave 
mode,  the  FPGA’s  clock  is  driven  by  an  external  source.  The  master  mode  was 
designed  so  that  the  FPGA  could  be  configured  from  a  serial  PROM  [55].  The 
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slave  mode  allows  the  FPGA  to  be  configured  from  other  logic  devices,  such  as 
microprocessors,  or  in  a  daisy-chain  fashion  [55].  The  master/slave  serial  mode 
is  depicted  in  Figure  40. 


(2)  SelectMAP.  SelectMAP  provides  an  “8-bit  bidirec¬ 
tional  data  bus  interface”  [55],  or  parallel  load  capability,  for  Virtex  devices.  This 
mode  may  be  used  for  both  configuration  and  for  readback,  and  provides  a 
means  for  the  device  to  be  partially  reconfigured  while  it  is  operating.  This  mode 
requires  a  controller  for  the  SelectMAP  interface,  typically  a  microprocessor  or 
CPLD.  In  this  mode,  devices  may  be  connected  in  a  parallel-chain,  but  not  seri¬ 
ally  [55].  Figure  41  shows  a  simple  SelectMAP  circuit. 


VPU  VPU 


Figure  41 .  SelectMAP  Configuration  Circuit  (From  Ref.  [56].) 
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(3)  JTAG.  JTAG  provides  a  serial  configuration  and  ver¬ 
ify  mechanism  as  well  as  provides  the  for  the  JTAG  protocol’s  behavioral  testing 
of  the  internal  circuit,  allowing  for  detection  of  opens  and  shorts  at  the  device  and 
board  level  [57].  The  Boundary  Scan  mode  is  always  active  when  the  device  is 
powered  [55],  although  through  careful  use  of  the  Virtex  mode  pins,  the  JTAG 
mode  may  be  deselected.  It  is  possible  to  chain  multiple  devices  using  JTAG,  as 
shown  in  Figure  42.  The  JTAG  mode  facilitates  test  and  development  of  configu¬ 
rations  by  its  design,  although  it  can  be  used  as  an  in  situ  readback  and  recon¬ 
figuration  method. 


JTAG  Header 


Device  0  Device  1  Device  2 


Figure  42.  JTAG-Chained  Virtex  Devices  (From  Ref.  [59].) 

b.  Readback  and  Reconfiguration 

As  mentioned  above,  in  addition  to  being  able  to  be  loaded  with  an 
initial  configuration  at  power  up  or  system  reset,  Virtex  FPGAs  provide  the  ability 
to  readback  their  configuration  as  well  as  to  reload  all  or  a  portion  of  their  con¬ 
figuration  while  the  device  is  in  operation.  This  is  a  tremendous  capability,  espe¬ 
cially  from  an  error  mitigation  standpoint  because  the  configuration  of  the  FPGA 
can  be  verified  while  it  is  in  operation.  Considering  that  the  configuration  of  the 
FPGA  is  defined  by  programming  tiny  memory,  interconnect,  and  logic  blocks,  an 
SEU  is  as  likely  to  affect  the  configuration  of  the  FPGA  as  it  is  to  affect  the  data 
the  FPGA’s  configuration  is  processing. 

In  order  to  readback  and  reconfigure  an  operating  FPGA,  the  de¬ 
vice  must  be  set  in  either  JTAG  or  SelectMAP  mode.  The  JTAG  method  of  read¬ 
ing  back  configuration  data  is  appealing  for  developers  due  to  the  probing,  test¬ 
ing,  and  verifying  functions  specified  in  the  JTAG  protocol  [57],  This  method  also 
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provides  for  partially  (or  completely)  reconfiguring  the  device  while  it  is  operation. 
A  potential  drawback  of  using  this  method  is  that  the  JTAG  pins  on  the  FPGAs 
are  always  available.  As  such  if  they  are  inadvertently  driven  high  or  low,  the 
possibility  for  configuration  contention  exists. 

The  SelectMAP  mode  enables  a  parallel  method  of  reading  back 
and  reloading  the  configuration  data.  In  this  mode  the  SelectMAP/User  10  pins 
must  be  dedicated  to  the  SelectMAP  mode  when  the  function  is  desired.  Be¬ 
cause  this  mode  is  only  available  when  the  three  mode  pins  on  the  device  are  set 
for  SelectMAP,  the  configuration  contention  problem  does  not  exist  as  with  the 
JTAG  mode. 

In  both  cases,  JTAG  and  SelectMAP,  a  controller  is  required  in  or¬ 
der  to  coordinate  the  readback  and  reconfiguration.  Depending  on  the  designer’s 
needs,  the  controller  can  validate  the  configuration’s  Cyclic  Redundancy  Code 
(CRC)  and  reconfigure  any  frame  of  data  that  is  in  error.  This  method  is  proces¬ 
sor  intensive  due  to  the  necessary  look  ups,  compares,  and  frame  configuration 
processes,  as  well  as  configuration  frame  fetches  from  configuration  storage.  A 
less  processor  intensive  method  is  to  periodically  scrub  the  current  configuration 
by  reloading  all  of  it.  This  technique  requires  very  little  processor  time,  but  lacks 
the  rapid  detection  and  repair  capability  that  the  comparison  method  offers.  The 
principle  drawback  of  partial  reconfiguration  or  scrubbing  is  that  is  only  available 
for  CLBs;  lOBs  and  BlockRAM  can  not  be  reconfigured  during  operation  without 
running  the  risk  of  disabling  the  lOBs  or  corrupting  data  in  BlockRAM. 

C.  PROGRAMMABLE  LOGIC  VS.  DISCRETE  LOGIC 

Another  trade  space  that  a  systems  designer  must  consider  is  whether  to 
use  discrete  components  to  perform  the  miscellaneous  functions  in  the  system, 
or  to  use  programmable  logic.  These  functions,  often  termed  ‘glue  logic,’  include 
multiplexers,  bus  transceivers,  buffers,  and  address  decoders,  to  name  a  few. 
Discrete  components  are  reliable,  proven  devices  that  can  be  procured  at  low 
cost  and  in  RADHARD  configurations.  For  small-scale  functions  they  provide  low 
density,  low  power,  simple  solutions  to  designers.  On  the  other  hand,  PLDs  offer 
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scalable  solutions  in  which  the  designer  may  be  able  to  incorporate  all  of  the  glue 
logic  into  a  single  component,  thus  reducing  device  density  on  the  PCB,  as  well 
as  possibly  reducing  cost  and  power  (design  dependent).  Programmable  logic 
may,  however,  add  a  level  of  complexity  to  the  design  of  the  circuit,  as  well  as  to 
the  layout  and  manufacture  of  the  PCB. 

A  final  thought  on  maximizing  the  use  of  programmable  logic  relates  to 
‘white  wires.’  These  are  the  artifacts  of  overlooked  connections,  forgotten  resis¬ 
tors,  and  layout  errors,  and  can  be  damaging  to  the  ego  of  any  engineer.  Utiliz¬ 
ing  programmable  logic  allows  the  system  designer  the  possibility  of  program¬ 
ming  away  errors  that  might  otherwise  be  repaired  by  adding,  or  scratching  off, 
interconnects. 

D.  PCB  DESIGN  PROCESS  AND  CONSIDERATIONS 

The  design  and  layout  of  a  PCB  is  an  engineering  discipline  unto  itself. 

The  rapid  advances  in  the  1C  industry  have  been  mirrored  in  the  PCB  industry. 
From  two-layer  PCB  technology  with  millimeter  traces  less  than  30  years  ago,  to 
17  layer,  25-pm  trace-width  technology  now  [58],  PCB  layout  has  evolved  from 
simple  topology  management  to  a  sophisticated  design  process.  The  design 
process  is  multifaceted  and  requires  attention  to  the  implementation  of  power  de¬ 
livery,  cooling  and  I/O  systems  [59].  Utilizing  one  or  more  FPGAs  in  a  design, 
especially  when  both  will  be  reprogrammed  in  situ,  makes  the  task  of  layout 
even  more  challenging,  as  power  requirements,  I/O  routing,  and  trace  imped¬ 
ances  will  vary  significantly  between  configurations.  A  generic  PCB  Design  Flow, 
including  FPGA  specifics,  is  presented  in  Figure  43. 
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PCB  Design  Flow 


FPGA  Specifics 


Product  $ 


•  FPGA  selection,  design  planning 

•  FPGA  resource  estimation 

•  FPGA  schematic  symbol  generation 

•  PCB  stackup  definition 

•  FPGA  and  board  clock  distribution  planning 

•  FPGA  thermal  management 

•  Static  timing  analysis  (pre-  &  post-layout) 

•  Signal  integrity  analysis  (pre-  &  post-layout) 

•  Power  distribution  system  analysis 

•  Design  for  test 


Figure  43.  PCB  Design  Flow  with  FPGA  Specifics  (From  Ref.  [59].) 


This  section  will  present  a  brief  discussion  of  a  few  of  the  things  that  must 
be  considered  when  design  a  PCB,  as  well  as  a  few  of  the  basic  design  rules. 

For  detailed  information  refer  to  References  [58  -  64]. 

1.  Software 

Software  tools  for  design  and  layout  of  PCBs  must  be  selected  carefully. 
This  software  can  be  very  expensive,  is  rarely  compatible  across  vendors,  and 
must  produce  a  file  that  the  fabrication  contractor  can  use.  Usability,  as  with  any 
software  package,  should  be  considered.  Does  the  software  support  the  tech¬ 
nology  and  the  process  of  your  design?  Are  the  desired  libraries  available,  if  not, 
can  they  be  created?  Are  there  tools  capable  of  verification  of  the  design? 
Questions  such  as  these  should  be  asked  when  determining  which  product  to 
select. 
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2.  Layers 


The  number  of  layers  in  a  PCB  will  depend  on  routing  requirements,  but 
should  at  least  have  three.  Every  board  must  have  continuous  ground  plane  and 
should  have  a  dedicated,  continuous  Vcc  plane,  as  well  as  a  power  plane  for  any 
other  distributed  voltage.  An  additional  consideration  for  layers  is  that  every 
trace  in  the  stack  should  be  not  more  than  one  layer  away  from  a  reference  plane 
(power  or  ground)  [61 ,  64],  Figure  44  shows  the  PCB  layering  concept. 


Lay-er  1 & 

Layer  P 
Layer  G 

Layer  7 
Layer  6 

Layer  5 
Layer  4 

Layer  Z 

Layer  2 

Layer  f 
Figure  44. 


Horizontal  R  ruling 

VerticaJ  Raiding 
Ground  Plane 

Her  cental  Railing 
Vertical  Routing 

HcrizoniaJ  Routing 
Verttal  Routing 

vcc  Plane 

HetEonrtaJ  Routing 


vertical  Rowing 

Layered  PCB  with  Varying  Trace  Widths  (From  Ref.  [61].) 


3.  Traces 


The  traces,  or  wires  etched  onto  PCBs,  must  have  the  same  impedance 
throughout  the  length  of  the  run.  Even  if  the  trace  should  transit  multiple  layers, 
the  trace  must  be  adjusted  to  maintain  constant  impedance  [61].  Figure  44  illus¬ 
trates  this  point,  by  showing  different  widths  of  traces  to  accommodate  different 
impedances.  Also,  long  traces  run  the  risk  of  transmission  line  reflection  and 
must  be  analyzed  accordingly.  Additionally,  closely  spaced,  long  lines  need  to 
be  analyzed  for  cross  talk. 
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4.  Capacitors 

Capacitors  are  required  throughout  the  board  in  order  to  stabilize  current 
flow  and  reduce  system  noise.  Decoupling  capacitors  need  to  be  included  with  1 
cm  to  2  cm  from  each  Vcc  pin  and  must  be  of  sufficient  value  to  supply  lcc  for  a 
few  nanoseconds  [62].  Additional  mid-frequency  and  low-frequency  capacitors 
are  need  for  FPGA  protection  as  well  as  for  the  board  as  a  whole. 

E.  CFTP  DESIGN  PROCESS  AND  SYSTEM  OVERVIEW 

Having  now  discussed  the  initial  conditions  of  the  CFTP  and  the  design 
considerations  that  define  the  scope  of  this  research,  an  overview  of  the  CFTP 
system  concept  will  be  provided.  The  CFTP  design  process  has  deviated  from 
the  typical  waterfall  approach  to  system  development.  Multiple  aspects  of  the 
design  of  the  total  system,  including  the  initial  soft  core  TMR  processor  and  the 
test  and  evaluation  plan  have  been  progressing  concurrently  with  the  design  of 
the  CFTP  PCB.  Throughout  this  non-standard  design  process,  the  NPSAT1 , 
MidSTAR-1,  and  STP  have  added  additional  design  and  development  require¬ 
ments  that  have  been  ongoing  in  the  background  of  the  entire  CFTP  design  pro¬ 
cess.  While  this  nonlinearity  seems  unusual,  this  process  has  enabled  a  small 
team  to  develop  a  comprehensive  program  in  a  very  short  time. 

The  CFTP,  in  its  current  version  as  a  reconfigurable  space  based  experi¬ 
ment,  began  as  a  simple  block  diagram  as  shown  in  Figure  33  (a).  From  that 
concept,  given  the  constraints  and  considerations  discussed  earlier,  and  the  mo¬ 
tivation  of  design  documentation  for  the  SERB  process,  the  CFTP  quickly 
evolved  to  become  the  concept  shown  in  Figure  45,  which  is  the  same  as  Figure 
1  described  on  page  4. 
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Figure  45.  CFTP  Intermediate  Conceptual  Illustration 


The  CFTP  concept  remained  in  the  form  shown  above  while  the  afore¬ 
mentioned  parallel  design  and  development  process  focused  on  STP  launch  ve¬ 
hicle/payload  integration.  This  aspect  of  the  design  process  provided  an  oppor¬ 
tunity  for  the  CFTP  technical  details  to  be  identified  and  resolved  in  order  to  sat¬ 
isfy  satellite  launch  integration  timelines. 

Eventually,  it  became  obvious  that  the  concept  was  in  need  of  further 
modification.  Through  a  rapid  succession  of  component  level  design  decisions, 
the  CFTP  evolved  into  its  final  version.  Figure  46  is  an  illustration  representing 
the  final  conceptual  design  of  the  CFTP.  In  this  figure,  two  FPGAs  are  depicted, 
the  top  left  illustrates  the  Configurable  Processor  FPGA  and  the  lower  left  depicts 
the  Configuration  Controller  FPGA  with  its  associaded  functions.  On  the  Right 
side  of  the  image  are  the  system  memory,  configuration  memory  and  left-over 
discrete  components. 
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Figure  46.  Final  CFTP  Concept 

F.  CHAPTER  SUMMARY 

This  chapter  has  provided  insight  into  the  background  of  the  CFTP  devel¬ 
opment,  as  well  as  a  discussion  of  the  significant  trade  spaces  that  define  the 
bounds  of  this  project.  The  conceptual  progression  of  the  CFTP  design,  given 
the  initial  design  framework  and  the  hardware  design  trade  space,  has  remained 
constant  in  purpose:  The  development  of  a  reliable,  fault  tolerant,  reconfigurable 
system  for  space  applications.  The  process  leading  to  the  final  CFTP  concept,  a 
product  of  numerous  trade-offs,  will  be  detailed  in  the  following  chapter  with  a 
discussion  of  the  specific  components  selected  and  the  reasoning  behind  those 
choices. 
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V.  CFTP  COMPONENTS 


Chapter  IV  presented  the  hardware  design  trade  space  based  on  the  con¬ 
straints  and  considerations  defined  for  the  CFTP.  The  intermediate  CFTP  con¬ 
cept  shown  in  Figure  48  represented  the  targeted  architecture  when  specific 
parts  selection  began  for  the  development  board.  From  this  starting  point,  both 
the  parts  selection  and  the  conceptual  design  refinement  progressed  concur¬ 
rently,  each  influencing  the  other.  This  mutually  reliant  relationship  between 
component  selection  and  design  evolution,  serves  as  an  example  of  the  non¬ 
linearity  of  the  CFTP  developmental  process  discussed  earlier.  The  refinement 
of  the  design  continued  through  the  entire  development  of  the  CFTP,  with  the 
design  not  becoming  truly  fixed  until  the  Printed  Circuit  Board  (PCB)  was  finally 
fabricated. 

Throughout  the  parts  selection/refinement  processes  there  existed  pro¬ 
curement  considerations,  both  fiscal  and  time  related.  Because  the  CFTP  is 
manifested  on  both  NPSAT1  and  MidSTARI,  at  least  five  boards  are  needed  to 
meet  the  requirements  for  the  scheduled  launch  of  both  satellites  in  March  2006. 
Five  was  determined  to  be  the  optimal  number  of  boards  to  achieve  the  test, 
evaluation,  and  space  qualification  goals.  However,  budget  constraints  at  vari¬ 
ous  junctures  of  the  development  cycle,  jeopardized  the  ability  to  build  five 
boards.  Fortunately,  careful  selection  of  parts  and  the  generosity  of  Xilinx  and 
SEAKR  Engineering  allowed  for  final  design  costs  to  be  within  allocated  funding. 
Table  9  summarizes  the  each  board’s  purpose  and  its  delivery  date. 


Board  # 

Purpose 

Delivery 

Notes 

1 

Test,  Eval,  Demo 

2  QTR  CY03 

Utilizes  developmental  hardware. 

2 

MidSTARI  Qual  Board 

4  QTR  CY03 

Flight  components;  for  space  qualification 
and  ground  systems  development  at  NPS 

3 

NPSAT1  Qual  Board 

4  QTR  CY03 

Flight  components;  for  space  qualification 
and  ground  systems  development  at  USNA 

4 

MidSTARI  Flight  Board 

2  QTR  CY04 

CFTP  FLIGHT  BOARD  1 

5 

NPSAT1  Flight  Board 

2  QTR  CY04 

CFTP  FLIGHT  BOARD  2 

Table  9.  CFTP  Board  Delivery 
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A.  RECONFIGURABLE  CORE 


The  heart  of  the  CFTP  is  the  reconfigurable  processor.  The  device  se¬ 
lected  for  this  purpose  in  Lieutenant  Lashomb’s  research  [8]  was  the  Xilinx 
XCV800  FPGA,  primarily  because  the  XCV800  is  the  largest  Xilinx  FPGA  not 
packaged  as  a  Ball  Grid  Array  (BGA).  Not  mentioned  in  Lieutenant  LaShomb’s 
thesis  was  the  TID  tolerance  of  the  device,  which  was  assumed  early  in  the 
CFTP  development  to  be  100  krad  TID  tolerant  and  SEL  immune.  While  it  is  true 
that  this  is  the  largest  Xilinx  device  available  in  a  Quad  Flat  Pack  (QFP),  it  is  not 
necessarily  valid  to  assume  that  these  parts  are  consistently  100  krad  TID  toler¬ 
ant.  Some  are,  but  it  is  by  luck  of  the  draw  only.  In  fact,  Xilinx  offers  only  a  lim¬ 
ited  selection  of  its  Virtex  family  as  guaranteed  RADHARD  to  100  krad — the 
XQVR  series.  The  XQVR  devices  are  available  in  the  300,  600,  and  1000  sizes 
(refer  to  Table  5  for  associated  gate  counts),  and  the  XQVR600  is  the  largest 
available  in  the  QFP  package.  While  this  fact  was  not  discovered  until  shortly 
before  the  order  was  to  be  placed,  it  alone  would  not  have  affected  the  decision 
to  purchase  the  commercial  XCV800  devices  due  to  cost  considerations.  To  il¬ 
lustrate  this  point,  the  commercial  XCV800  can  be  purchased  for  less  that  $1500 
[66]  as  an  industrial  class  chip  in  the  fastest  speed  grade,  while  the  XQVR600,  a 
smaller  device  with  slower  operating  speed,  costs  approximately  $7000  [67]. 
Considering  that  each  of  the  five  boards  needs  one  of  these  devices  and  that  a 
goal  of  the  CFTP  was  to  mitigate  errors  while  maximizing  the  use  of  COTS  tech¬ 
nology  (as  well  as  to  have  a  device  that  was  large  enough  to  instantiate  state-of- 
the-art  microprocessors),  it  seemed  reasonable  and  fiscally  prudent  to  move  for¬ 
ward  with  the  purchase  of  the  XCV800.  This  was  to  change. 

During  the  course  of  confirming  XCV800’s  operating  characteristics,  Xilinx 
offered  to  donate  to  the  CFTP  design  evaluation  samples  of  any  RADHARD 
parts  desired  [68].  The  opportunity  to  use  RADHARD  components  could  not  be 
passed  up,  thus  the  final  design  of  the  CFTP  is  based  on  the  Xilinx  XQVR600- 
4CB228M  FPGA  (Figure  47  shows  the  part  number  information). 
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Example: 

Device  Type  - 


XQVR1000  -4  CG  560 


Speed  Graded 


Manufacturing  Grade 
Number  of  Pins 
Package  Type 


Device  Ordering  Options 


Device  Type 


XQVR300 


XQVR600 


XQVR1000 


Package 

CB228 

228-pin  Ceramic  Quad  Flat  Package 

CG560 

560-column  Ceramic  Column  Grid  Package 

Notes: 

1 .  -4  only  supported  speed  grade. 

2.  Class  Q  must  be  ordered  with  SMD  number. 


Grade 

M 

Military  Ceramic 

Tc  =  — 55°C  to  +125°C 

V 

QPro  Plus 

Tc  =  — 55°C  to  +125°C 

Q 

MIL-PRF-38535<2> 

Tc  =  — 55°C  to  +125°C 

Figure  47.  Example  Xilinx  RADHARD  Device  Numbering  (From  Ref.  [34].) 


The  XCV800-based  design  used  a  single  XCV800  to  contain  the  memory 
controller,  memory  EDAC  logic,  as  well  as  the  TMR  processors  and  the  neces¬ 
sary  voters.  The  layout,  interconnections,  and  busses  required  to  support  this 
logical  arrangement  had  been  completed  based  on  the  assumption  that  the 
XCV800  would  be  sufficiently  large  to  “hold”  these  cores,  as  well  as  have  suffi¬ 
cient  capacity  to  implement  larger,  more  sophisticated  TMR  microprocessors  in 
the  future.  Selecting  the  XQVR600  as  the  FPGA  reduced  the  available  gate 
count  by  25%,  from  888,439  to  6661 ,1 1 1 .  Consequently,  the  layout  was  re¬ 
designed  to  support  placing  the  memory  controller  and  EDAC  logic  outside  of  the 
primary  FPGA  device  to  provide  more  gates  to  implement  future  IP  microproces¬ 
sors. 

B.  SYSTEM  MEMORY 

The  CFTP’s  baseline  concept  at  the  onset  of  this  thesis  research  included 
legacy  SRAM  system  memory,  implemented  with  Toshiba  TC55V8200FT-12 
chips.  Both  the  EDAC  and  the  controller  coding  were  essentially  complete  and, 
because  the  memory  had  been  fully  tested  and  flown  on  PANSAT,  it  was  consid¬ 
ered  low  risk  for  use  in  CFTP.  Additionally,  this  memory  was  attractive  because 
it  was  easy  to  implement,  inexpensive,  and  readily  available.  Flowever,  the 
SRAM  had  two  significant  drawbacks,  size  and  power.  For  example,  to  imple¬ 
ment  16  MB  of  SRAM  with  8  bits  per  word  of  ECC  requires  12  chips  (1  by  0.5 
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inches  each)  and  uses  3.78  Watts  [69].  Having  the  system  memory  selection 
made  at  the  start  of  the  program  allowed  efforts  to  be  focused  on  other  compo¬ 
nents.  This,  also,  was  to  change. 

Early  in  the  development  of  the  CFTP,  one  of  the  potential  IP  cores  for  the 
Configurable  Processor  (CP),  while  onboard  NPSAT1,  was  SEAKR  Engineer¬ 
ing’s  proprietary  image  compression  engine.  As  the  relationship  between  NPS 
and  SEAKR  grew,  SEAKR  offered  to  supply  a  small  lot  of  SDRAM  parts  that 
were  excess  from  a  tested  and  qualified  lot.  Initially,  the  legacy  SRAM  was  more 
appealing  than  attempting  to  integrate  the  SDRAM  into  the  CFTP  design,  given 
the  uncertainty  of  the  number  of  chips  the  CFTP  would  receive  from  SEAKR  and 
the  complexity  of  employing  and  controlling  SDRAM.  Eventually,  SEAKR  offered 
to  provide  their  SDRAM  Controller  IP  core  written  for  Virtex  devices,  in  addition  to 
a  batch  of  30  Hitachi  (now  ELPIDA)  HM5225405B-75  256M  (16M-word  x  4-bit  x 
4-bank)  SDRAM  [70  -  73].  This  lot  of  Hitachi  SDRAM  performed  in  testing  to 
better  than  40  krad  TID  with  an  SEL  Threshold  of  46.5  MeV-cm2/mg  [74,  75]. 

The  space  qualified  SDRAM  and  the  IP  controller  core  made  the  offer  too  good 
to  pass  up,  as  a  result  Hitachi  SDRAM  is  included  in  the  final  design  of  the 
CFTP. 

The  30  SDRAMs  were  enough  to  meet  the  CFTP  requirement  for  five 
boards,  providing  the  existing  memory  architecture  was  redesigned.  In  order  to 
use  this  memory  on  all  five  of  the  boards,  a  maximum  of  six  devices  per  board 
could  be  used.  This  required  the  memory  architecture  to  be  redesigned.  The 
result  was  a  24-bit  wide  word  memory  structure,  using  16-bits  for  data  and  allow¬ 
ing  a  maximum  of  8-bits  of  ECC  to  be  stored  with  each  word.  While  this  structure 
is  not  the  32-bit  optimized  architecture  that  was  originally  conceived,  it  certainly 
meets  the  objectives  of  the  CFTP  offering  a  reliable  and  flexible  solution.  Addi¬ 
tional  benefits  are  that  six  SDRAM  chips  (instead  of  12),  using  slightly  less  power 
(about  3.3  Watts  at  50  MHz),  provide  the  CFTP  with  approximately  1.5  Gbits 
(192  MB)  of  memory. 


74 


c. 


CONFIGURATION  MEMORY 


One  of  the  characteristics  of  an  SRAM-based  FPGA  is  that  it  is  an  entirely 
volatile  device,  in  so  much  as  it  will  not  retain  its  configuration  or  the  data  that  it 
was  processing  if  the  power  is  removed.  Therefore,  the  configuration  must  be 
stored  in  an  external,  non-volatile  storage  device.  The  early  CFTP  concepts  in¬ 
cluded  a  combination  of  RADHARD  PROM,  EPROM  and  EEPROM.  The  PROM 
was  to  hold  the  start-up  configuration  containing,  perhaps,  a  Built-In  Self  Test 
(BIST),  the  necessary  settings  to  enable  configuration  from  the  EPROM  and/or 
EEPROM,  and/or  the  necessary  cores  to  provide  basic  communications  with  the 
PC/104  bus.  The  EPROM  would  contain  the  TMR  microprocessor,  with  EDAC 
and  SDRAM  controller,  and  an  EEPROM  loading-control  core,  in  addition  to  nec¬ 
essary  command  and  status  registers.  The  EEPROM  could  also  hold  some 
number  of  experimental  configurations  and  could  be  uploaded  across  the  PC/104 
bus  whenever  desired.  For  example,  SEAKR’s  image  compression  core  could 
be  stored,  as  could  a  communications  routing  protocol.  These  cores  could  then 
be  loaded  on  command  from  the  NPS  or  USNA  ground  stations  for  experimental 
use  on  orbit,  in  real  time.  The  reasoning  behind  employing  the  various  types  of 
ROM  was  based  on  early  reliability  assessments.  This  also  has  been  changed. 

As  various  ROM  technologies  were  investigated  for  suitability,  two  rea¬ 
sonable  alternative  EEPROM  devices,  one  from  Intel  and  one  from  Samsung, 
were  considered,  based  on  the  testing  done  by  other  programs  around  the  coun¬ 
try  [70,  74],  While  these  two  flash  technologies  were  being  explored,  it  became 
clear  that  interfacing  the  non-volatile  storage  with  the  Configurable  Processor 
would  be  challenging.  It  was  at  this  point  that  the  Xilinx  XC1 7Vxx  and  XC1 8Vxx 
families  of  configuration  PROM  became  the  selection  for  implementation.  These 
two  families  of  PROM  are  designed  by  Xilinx  to  directly  interface  and  conven¬ 
iently  serve  up  configurations  to  the  Xilinx  FPGAs.  The  XC17Vxx  family  of  Serial 
PROMs  are  One-Time  Programmable  (OTP)  devices  with  RADHARD  versions 
(the  XQR17Vxx  family)  [76,  77],  The  XC18Vxx  family  of  devices  are  In-System 
Programmable  (ISP)  devices  (JTAG  only)  that  can  parallel  load  FPGAs  in  the  Se- 

lectMAP  mode,  and  are  advertised  to  have  a  RADHARD  version  available  [76, 
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78,  79].  Using  Xiliinx  PROMs  provided  an  easy-to-integrate  solution  to  the  con¬ 
figuration  conundrum.  Yes,  this  too  was  to  change. 

It  became  clear  during  layout  that  the  simple  configuration  architecture 
utilizing  Xilinx  PROMs  would  not  suit  the  needs  of  the  CFTP.  Digging  deeper 
into  controlling  the  loading  of  the  PROMs,  controlling  the  FPGA  configuration, 
and  controlling  the  readback/partial  reconfiguration/background-scrubbing  SEU- 
mitigation  routines,  it  was  found  that  the  PROM  devices  would  only  be  able  to 
work  as  desired  if  a  sophisticated  microcontroller  or  a  microprocessor  was  used 
as  a  configuration  controller  (discussed  in  the  next  section).  Additionally,  Xilinx 
indicated  that  the  RADHARD  XQR18V04  PROM  would  no  longer  be  available 
due  to  manufacturing  problems  and  that  replacement  devices  have  not  yet  been 
tested,  further  complicating  the  selection  process.  As  these  discoveries  were 
made,  the  Hitachi  and  Samsung  Flash  memory  were  again  considered  as  pri¬ 
mary  alternatives.  The  Intel  TE28F320C3BA  32Mbit  flash  memory  was  eventu¬ 
ally  chosen  to  store  all  of  the  Configurable  Processor  FPGA’s  configurations  be¬ 
cause  research  indicated  that  it  has  better  radiation  performance  than  the  Sam¬ 
sung  alternative  [70,  74,  80,  81].  This  flash  memory  is  capable  of  holding  as 
many  as  eight  configurations  for  the  FPGA,  interfaces  easily  with  the  device,  and 
has  straight-forward  control  requirements  for  both  reading  from  and  writing  to  it 
[81]- 

D.  CONFIGURATION  CONTROLLER 

Configuring  the  Configurable  Processor  FPGA,  as  mentioned  in  the  previ¬ 
ous  paragraph  requires  some  form  of  a  controller.  This  fact  was  not  identified 
until  after  the  intermediate  concept  (reference  Figure  48),  when  the  issue  of  con¬ 
figuration  memory  required  reassessment.  However,  when  the  need  for  a  con¬ 
troller  became  clear,  it  was  determined  that  the  device  must  be  RADHARD  due 
to  its  critical  role.  Because  the  configuration  memory  devices  were  to  be  Xilinx 
PROMs,  the  first  device  chosen  as  a  configuration  controller  was  a  Xilinx  CPLD. 
In  short  order,  Xilinx  CPLDs  were  discounted,  because  no  suitable  RADHARD 
devices  were  available. 
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Actel  antifuse  FPGAs  were  the  next  logical  fit  given  their  demonstrated 
RADHARD  designs  and  their  impressive  flight  heritage.  The  two  primary  families 
of  radiation  tolerant  and  RADHARD  devices  (R  SX-A  and  RH  1020/1280  Fami¬ 
lies)  offered  mixed  benefits.  True,  they  are  RADHARD,  reliable,  devices,  with 
affordable  design  tools  and  device  programming,  but  they  are  small  (low  gate 
count,  refer  to  Table  5),  OTP  devices,  with  very  high  price  tags  ($3650  for 
RT54SX32S  and  over  $10,000  for  RH1280  [82]).  After  weighing  the  options,  the 
RT54SX32S  was  chosen,  providing  32,000  gates  with  a  TID  tolerance  greater 
than  100  krad,  total  SEL  immunity,  and  SEU  immune  to  greater  than  50  LET  [54], 
thereby  providing  solid  RADHARD  performance  at  the  most  reasonably  available 
price.  However,  this  too  changed. 

Shortly  after  the  selecting  the  Actel  device  as  the  Configuration  Controller 
(CC),  Xilinx  made  the  RADHARD  offer  discussed  in  Section  A,  above.  Using  the 
Xilinx  XQVR600  for  the  Configuration  Controller  was  immediately  appealing  for  a 
number  of  reasons,  including  the  cost  savings,  the  form  factor,  the  design  tool, 
and  the  product  familiarity.  However  using  a  reprogrammable  SRAM  based 
FPGA,  even  the  RADHARD  XQVR  device,  increases  the  susceptibility  of  the 
Configuration  Controller  to  SEEs.  In  order  to  mitigate  these  effects  and  maxi¬ 
mize  the  ability  of  this  device  to  meet  the  desired  reliability  requirements  men¬ 
tioned  in  the  previous  paragraph,  some  control  measures  were  put  in  place. 

First,  the  XQVR  Configuration  Controller  would  be  used  in  role  similar  to  a  CPLD, 
without  frequent  reconfigurations  and  the  associated  EEPROM  support  that  is 
expected  of  the  Configurable  Processor  FPGA.  Second,  a  RADHARD  Xilinx 
OTP  PROM  would  be  used  as  the  configuration  storage  for  the  device  using  the 
dedicated  Master  Serial  configuration  mode  (which  loads  the  configuration  by  de¬ 
fault  when  power  is  applied  or  when  the  system  is  reset).  The  third  control 
measure  was  to  utilize  background  scrubbing  of  the  device  while  it  is  operation 
with  a  refresh  frequency  optimized  for  the  predicted  SEU  rates  for  each  orbit. 

This  will  require  the  device  to  serve  as  its  own  scrubbing  controller  and  watchdog 
timer,  an  IP  core  for  which  is  under  development  at  Xilinx  [82],  Fourth,  because 
the  device  is  after  all  reconfigurable,  the  capability  to  configure  and/or  scrub  the 
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device  using  the  Reconfigurable  Processor  FPGA  has  also  been  provided  for  as 
a  backup.  Including  these  control  measures,  along  with  TMR  instantiation  of  the 
soft  cores,  it  is  expected  that  the  reliability  requirement  for  the  Configuration  Con¬ 
troller  FPGA  will  be  met. 

E.  FUNCTIONAL  LOGIC 

Several  necessary  control  and  reliability  functions  have  been  mentioned 
throughout  this  Chapter,  including  the  use  of  an  SDRAM  controller,  configuration 
controllers  for  both  FPGAs,  readback/partial  reconfiguration/scrubbing  control¬ 
lers,  and  EDAC  logic.  In  addition  to  these  functions,  normal  operation  of  the 
CFTP  as  a  system  includes  interface  management,  command  and  status  regis¬ 
ters,  interrupt  handling/control,  and  system  data  handling  for  communications  to 
the  satellite  and  ground  stations  (protocol  management).  As  functions  such  as 
these  have  been  identified  throughout  the  design  process,  they  had  been  col¬ 
lected  in  a  conceptual  package  referred  to  as  Random  Left-Over  Stuff  (RLOS). 
Until  the  Configuration  Control  FPGA  took  shape,  consideration  was  being  given 
to  the  implementation  of  RLOS  in  discrete  components.  When  the  selected  Con¬ 
figuration  Controller  was  the  Actel  device,  it  was  expected  that  most  of  the  RLOS 
could  be  instantiated  within  the  32,000  available  gates.  However  using  the  Xilinx 
XQVR600  FPGA  with  661 ,1 1 1  gates,  it  is  expected  to  contain  all  of  the  RLOS. 
Table  10  summarizes  the  functions  to  be  performed  by  each  device  in  the  CFTP. 

F.  GLUE  LOGIC 

Closely  related  to  the  RLOS  mentioned  above  are  the  essential  linking 
and  interface  functions.  While  these  are  often  considered  trivial  in  the  large  pic¬ 
ture,  they  are  absolutely  necessary  for  the  system  to  operate  properly.  Included 
in  this  category  are  bus  transceivers  (buffers),  address  decoding,  an  oscillator, 
Direct  Current  (DC)  voltage  converters,  bypass  (or  decoupling)  capacitors  for  cir¬ 
cuit/device  protection,  and  pull-up/pull-down  resistors.  Initially,  all  of  these  func¬ 
tions  were  to  be  implemented  in  discrete  logic.  For  example,  54HC245  octal  bus 
transceiver  chips  were  going  to  be  used  between  the  PC/104  bus  and  the  CFTP 
devices  for  directional  control  and  buffering.  Because  of  the  size  of  the  FPGA 

chosen  as  the  Configuration  Controller,  some  of  this  logic,  such  as  the  transceiv- 
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ers  and  the  address  decoding,  can  be  moved  to  the  FPGA  which  further  reduces 
the  footprint  and  power  requirements.  Some  devices  can  not  be  substituted  by 
the  functionality  of  the  FPGA,  these  include  resistors,  capacitors,  DC-DC  voltage 
regulators/converters,  and  oscillators.  Discrete  component  functions  are  also  in¬ 
cluded  in  Table  10. 


Device 

Primary  Function 

Alternate/Secondary  Func¬ 
tions 

Potential  Future  Uses 

Xilinx  XQVR600 
FPGA 

Configurable  Processor 

TMR  Microprocessors 

Image  Compression 

Network/Communications 

Routing 

Satellite  On-Board  Systems 
redundancy/Back-up 

DSP 

Most  functions  listed  for  Con¬ 
figuration  Controller 

Future  Functions  TBD 

Xilinx  XQVR600 
FPGA 

Configuration  Controller 

SDRAM  Configuration  Controller 

Bus  Master  Functions 

ED  AC  Controller 

Communications  Control 

JTAG  Controller 

Future  Functions  TBD 

Readback,  Partial  reconfigura¬ 
tion,  and  background 

CFTP  Interrupt  Handling/Control 

Command  and  Status  registers 

Bus  Address  Decoding 

PC/104  Bus  interface 

Xilinx  XC18V04 
ILP  PROM 

Developmental  Configu¬ 
ration  Storage  for  Con¬ 
figuration  Controller 

Will  be  replaced  by  XQR17V16 
for  flight 

Xilinx 

XQR17V16 

Flight  Configuration  Stor¬ 
age  for  Configuration 
Controller 

Up  to  8  additional  configurations 
including  BIST  and  Status  Re¬ 
porting 

Future  Configurations  TBD 

Intel  28F320C3 
Flash 

Configuration  Storage  for 
Configurable  Processor 

Storage  for  Operating  Sys¬ 
tem/Codes 

Extra  application  space  for  mi¬ 
croprocessor 

Hitachi  SDRAM 

System  Memory 

User  defined  storage 

3.3V  Regulator 

5V  to  3.3V  Conversion 

2.5V  Regulator 

3.3V  to  2.5V  Conversion 

Oscillator 

Socket 

Clock  Signal  Develop¬ 
ment 

Optimized  Flight  Board  Oscillator 
(TBD) 

Table  10.  CFTP  Device  Functions 


G.  PRINTED  CIRCUIT  BOARD 

PCB  layout  is  a  time  consuming  task  requiring  a  considerable  amount  of 
design  troubleshooting  throughout.  Using  special  software,  Accel  Technologies’ 
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P-CAD9,  the  selected  parts  must  be  created,  placed  in  a  schematic  editor,  and 
pins  assigned,  from  which  the  net  list  is  generated.  After  the  devices  are  input 
into  the  program,  the  board  itself  must  be  defined,  including  shape,  dimensions, 
obstructions  (e.g.,  bolt  holes),  design  rules,  and  the  number  of  board  layers.  Fi¬ 
nally  the  physical  traces,  vias,  and  interconnects,  based  on  the  actual  dimen¬ 
sions  of  the  parts  and  board,  are  routed.  Throughout  this  Computer  Aided  De¬ 
sign  (CAD)  entry  phase,  numerous  verification  and  validation  steps  must  be  ac¬ 
complished.  It  has  been  through  this  process  that  several  routing  issues,  requir¬ 
ing  slight  conceptual  changes,  have  been  brought  to  light,  such  as  the  JTAG  de¬ 
vice  interconnections.  Multilayer,  complex  PCB  layout,  as  mentioned  in  Chapter 
IV,  requires  a  particular  skill  set.  After  the  design  has  passed  final  verification 
checks  and  meets  the  design  rules  of  the  manufactures  process  specifications,  it 
is  then  sent  out  for  fabrication.  For  the  CFTP,  Advanced  Circuits10  is  the  PCB 
manufacturer.  Once  back  from  fabrication,  the  parts  that  were  not  installed  by 
Advanced  Circuits  are  soldered  on  under  microscope  at  NPS,  a  very  exacting 
procedure. 

H.  CHAPTER  SUMMARY 

Throughout  the  CFTP’s  design,  considerable  effort  has  been  spent  to 
maximize  functionality,  within  the  scope  of  the  projects  goals,  while  minimizing 
costs.  As  opportunities  were  presented,  such  as  Xilinx’s  offer  of  RADHARD  de¬ 
vices  and  SEAKR’s  donation  of  SDRAM,  great  efforts  were  taken  to  analyze  al¬ 
ternatives  in  order  to  select  the  one  most  in  accordance  with  design  and  func¬ 
tional  goals.  This  has  meant  that  the  CFTP  was  “redesigned”  several  times  over 
the  past  two  years,  but  the  underlying  concept  has  not  changed.  The  final  CFTP 
design,  spawned  from  this  original  concept,  will  be  presented  in  Chapter  VI. 


9  P-CAD  is  a  registered  trademark  of  Accel  Technologies,  Inc. 

10  Advanced  Circuits,  21101  East  32nd  Parkway,  Aurora,  CO  8001 1 
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VI.  THE  COMPLETE  CFTP 


The  goal  of  designing  a  reliable,  reconfigurable  processor  for  space  appli¬ 
cations  has  been  the  overarching  theme  of  the  CFTP  development  since  its  in¬ 
ception.  From  the  early  conceptual  stages,  characterized  by  the  diagrams  shown 
in  Figures  36  (a)  and  (b),  the  CFTP  design  process  has  focused  on  maximizing 
available  resources  to  deliver  the  most  robust  and  flexible  system  possible. 

The  component  selection  and  design  refinement  processes  have  resulted 
in  a  system  ready  for  final  assembly,  leading  to  test  and  evaluation.  The  final 
component  choices  provide  for  a  radiation  tolerant  system  with  an  architecture 
that  supports  maximum  flexibility  in  application. 

A.  COMPONENT  INTEGRATION 

Chapter  V  described  a  system  design  process  heavily  focused  on  concur¬ 
rent  component  selection.  As  parts  were  selected,  the  architecture  was  changed 
to  suit  component  specific  implementations,  which  led  to  concept  changes,  which 
would  then  require  different  parts.  This  process  continued  throughout  the  entire 
process,  including  the  final  stages  of  PCB  layout  and  the  physical  assignment  of 
pins  on  devices  and  laying  traces  on  the  board.  The  end  result,  however,  is  the 
CFTP  shown  as  a  block  diagram  in  Figure  48. 
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Figure  48.  CFTP  Final  Block  Diagram 

1 .  Data  paths 

The  CFTP  architecture  was  designed  with  maximum  flexibility  to  support 
future,  yet  to  be  determined,  IP  cores.  This  required  logic  paths  to  be  created 
between  the  CFTP’s  components  as  well  as  between  the  CFTP  and  the  system 
host,  for  multiple  functions,  many  without  specific  definition. 

a.  Primary  Design  Architecture 

The  CFTP  primary  design  architecture  supports  the  TMR  KDLX  mi¬ 
croprocessor  developed  in  References  [9]  and  [10],  running  in  the  Configurable 
Processor  FPGA  with  the  SDRAM  controller  and  EDAC  controller  cores  also  in¬ 
stantiated  in  that  FPGA.  The  Configuration  Controller  FPGA  would  then  be  re¬ 
sponsible  for  controlling  the  background  partial  reconfiguration  of  the  Processor 
FPGA,  providing  PC/104  Bus  Interface  services,  provide  a  Command  and  Status 
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register,  satellite  C&DH  interrupt  handling  functions  and  bus  address  decoding, 
as  well  as  providing  its  own  background  SEU-mitigating  scrub  routine  control. 
This  concept  is  graphically  depicted  in  Figure  49.  Control,  data  and  address  sig¬ 
nals  across  the  PC/104  bus  trigger  the  Configuration  Controller  (CC)  to  configure 
in  its  initial  state  from  the  PROM,  which  in  turn  commands  and  controls  the  initial 
configuration  of  the  Configurable  Processor  (CP)  from  the  flash  memory.  During 
normal  operations,  the  CP  will  utilize  the  SDRAM  for  its  processor  memory  while 
the  CC  controls  background  configuration  scrubbing  of  the  CP  using  the  flash 
memory.  Also,  the  CC  will  control  its  own  background  scrubbing  (self-scrubbing 
mode)  using  the  configuration  stored  in  the  PROM.  If  the  either  the  CP  or  the  CC 
require  bus  attention,  then  it  is  the  CC’s  responsibility  to  negotiate  the  interrupt 
service  and  handling  routines  with  the  host  system. 
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Figure  49.  Baseline  Architecture  of  the  CFTP 
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b.  Alternate  and  Additional  Paths 

Considering  that  the  XQVR600  may  eventually  be  too  small  to  con¬ 
tain  TMR  microprocessor  cores  and  the  additional  controllers  mentioned  above, 
multiple  direct  traces  connect  the  user  configurable  I/O  pins  of  the  two  FPGAs. 
This  allows  for  moving  various  “components”  of  the  architecture  to  one  or  the 
other  FPGA,  depending  on  the  designers  constraints.  For  example,  one  of  the 
three  microprocessors  that  make  up  the  TMR  architecture  could  be  moved  from 
the  Configurable  Processor  to  the  Configuration  Controller,  allowing  for  larger 
microprocessor  IP  cores  to  be  used.  Anticipating  “unknown-unknowns,”  addi¬ 
tional  paths  have  been  designed  into  the  CFTP.  A  45-bit-wide  dedicated  path 
exists  between  the  two  FPGAs,  conceptually  for  the  PC/104  to  exchange  data 
directly  with  the  Configurable  Processor,  via  the  bus  transceiver  logic  instantiated 
in  the  Configuration  Controller  FPGA.  The  42-bit-wide  Flash  memory 
data/address/  control  busses  are  paralleled  between  the  FPGAs,  providing  an 
additional  FPGA  to  FPGA  path.  It  is  worth  mentioning  that  the  user  I/O  FPGA 
pins  (all  of  which  these  are)  can  be  internally  configured  for  a  number  of  input 
and  output  functions,  including  pull-up,  pull-down,  and  high  impedance  condi¬ 
tions.  Thus,  depending  on  the  operating  configurations  of  the  two  FPGAs,  these 
paths  can  be  used  between  the  FPGAs  and  or  between  the  Flash.  Additionally, 
the  pins  that  are  dual  use  for  configuring  the  devices  and  as  user  10  are,  for  the 
most  part,  connected  in  parallel  between  the  devices  providing  further  on-board 
flexibility  (more  on  configuring  in  the  next  Section).  Figure  50  highlights  the  addi¬ 
tional  and  alternate  paths  in  the  CFTP  architecture  providing  for  future  flexibility 
in  architectural  designs. 
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Figure  50.  Additional  CFTP  Connections 


2.  Configuration  Methods  and  Paths 

Designing  suitable  configuration  capabilities  for  the  CFTP  to  achieve  req¬ 
uisite  SEE  tolerance  has  complicated  the  design  process.  The  constraints  to  the 
designer  include:  the  number  of  available  pins  on  the  CB228  packages;  the  deci¬ 
sion  to  use,  and  how  best  to  employ,  partial  reconfiguration  and  scrubbing  as  er¬ 
ror  mitigation  techniques;  and  the  need  to  ensure  the  Configuration  Controller 
FPGA  is  designed  to  be  as  RADFIARD  as  possible.  The  final  CFTP  design  in¬ 
cludes  a  wide  variety  of  choices  for  the  programmer.  Thus  the  design  presented 
maximizes  flexibility  of  the  FPGAs  by  including  JTAG  readback  and  reconfigura¬ 
tion  controller,  SelectMAP  reconfiguration  controller,  Master-Slave  Serial  load, 
and  self-scrubbing  functions.  Table  1 1  summarizes  the  methods  available  for  the 
CFTP’s  FPGAs  to  be  configured.  Table  12  has  the  configuration  codes  for  each 
mode. 
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SI  Serial:  Slave  Serial  mode 
Mas.  Ser:  Master  Serial  mode 
Initialize  refers  to  power-off/hard  reset 
Reconfigure  refers  to  power-on/soft  reset 

Scrubbing  refers  to  any  reconfiguration  occurring  in  the  background  of  normal  operations _ 

Table  1 1 .  Configuration  Methods  for  Configurable  Processor  (CP) 
and  Configuration  Controller  (CC)  FPGAs 
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Table  12.  Configuration  Codes  for  Virtex  Devices  (From  Ref.  [44].) 

a.  Joint  Test  Action  Group  (JTAG)  /  Boundary  Scan 

Boundary  Scan  provides  a  very  useful  developmental  method  of 
loading,  reading  back  and  testing  configurations,  as  well  as  providing  a  method 
for  background  configuration  scrubbing  without  interrupting  surface  processing. 
The  JTAG  functionality  in  the  CFTP  is  provided  for  two  principal  reasons.  First,  it 
is  easy  to  use  and  it  conveniently  interfaces  with  desktop  Personal  Computers 
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(PCs)  supported  by  useful  development  software.  Second,  the  protocol  supports 
robust  test  functions  so  this  will  be  the  preferred  method  of  loading  the  configur¬ 
able  devices  on  the  board  during  development.  Third,  it  will  be  via  the  JTAG  port 
that  the  Configurable  Processor  FPGA  performs  its  SEU  mitigation  background 
scrubbing  while  on-orbit,  a  capability  also  provided  for  in  the  Configurable  Proc¬ 
essor.  The  JTAG  daisy  chain  is  shown  in  Figure  51,  and  the  self-scrubbing 
JTAG  path  is  shown  for  the  Configuration  Controller  in  Figure  52.  The  Configur¬ 
able  Processor  is  also  designed  with  this  capability,  although  it  is  not  shown 
here. 
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Figure  52.  JTAG  Self-Scrubbing 

b.  SelectMAP 

The  primary  method  of  loading  the  Configurable  Processor  FPGA 
will  be  through  the  SelectMAP  port.  This  method  provides  for  8-bit-wide  parallel 
loading  of  the  device  and  is  the  preferred  method  for  performing  background  con¬ 
figuration  readback  and  partial  reconfiguration.  There  are  two  principal  draw¬ 
backs  when  using  the  mode.  First,  although  the  SelectMAP  pins  are  dual-use, 
they  must  be  dedicated  to  configuration  loading  when  the  readback/recon- 
figuration  scheme  is  utilized.  Secondly,  this  method  requires  an  external  control¬ 
ler.  Therefore,  the  CFTP  design  allows  either  FPGA  to  act  as  the  Select  MAP 
controller  for  the  other  device.  The  block  diagram  with  the  Configurable  Proces¬ 
sor  in  SelectMAP  is  shown  in  Figure  53. 
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Figure  53.  CFTP  SelectMAP  Configuration  Diagram 
c.  Master-Slave  Serial  Mode 


The  Master  Serial  mode  is  the  default  method  of  loading  a  configu¬ 
ration  into  a  Xilinx  Virtex  FPGA.  This  method  was  selected  to  be  the  fail  safe 
mode  to  load  the  Configuration  Controller  FPGA  with  its  initial  configuration,  as  it 
is  extremely  simple  and  requires  no  external  clocking.  When  the  power-on/reset 
command  is  given  to  the  CFTP,  the  Configuration  Controller  will  be  loaded  from 
the  RADHARD  SPROM  via  the  Master  Serial  Mode,  with  no  controller  required. 
As  an  additional  option,  the  Processor  FPGA  can  be  daisy  chained  in  Slave  Se¬ 
rial  Mode  and  loaded  from  the  same  SPROM.  Figure  54  depicts  the  Master- 
Slave  Serial  Mode  as  used  in  the  CFTP. 
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Figure  54.  CFTP  Master-Slave  Serial  Mode 

B.  CFTP  PCB 

The  CFTP  PCB  was  laid  out  in  P-CAD  Schematic  editor,  which  provided 
for  pin  descriptions  and  net  identifications.  (Schematics  are  provided  in  Appen¬ 
dix  B.)  Using  the  net  list  generated  from  the  schematic  editor  and  the  exact  me¬ 
chanical  descriptions  of  the  parts,  the  physical  layout  of  the  traces,  vias  and  in¬ 
terconnects  was  completed.  Given  the  number  of  traces  to  be  run  on  the  board, 
the  dimensions  of  the  devices,  and  the  capacitor  requirements,  an  8-layered  PCB 
design  was  selected.  This  provided  for  a  dedicated  ground  plane,  a  Vccint  (+2.5 
V)  plane,  a  Vcco  (+3.3  V)  plane  and  five  planes  to  run  traces  in.  The  CFTP  PCB 
layers  are  shown  in  Figure  55. 
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The  final  PCB  design  was  verified  in  the  software  against  design  rules 
specified  by  the  manufacturer,  such  as  via  proximity,  minimum  trace  width,  and 
minimum  hole  diameters.  Once  verified,  the  design  was  sent  to  the  manufacturer 
as  a  “Gerber11”  file  from  which  the  PCB  is  fabricated.  The  Gerber  file  provided  to 
the  PCB  manufacturer  is  not  included  in  this  thesis  due  to  its  sheer  size;  however 
it  will  be  maintained  in  the  SSAG  [83].  Schematic  diagrams  and  individual  PCB 
layer  diagrams  are  also  provided  in  Appendixes  B  and  C,  respectively.  Figure  56 
shows  the  complete  CFTP  8-layer  PCB  layout. 

With  the  hardware  designed  and  parts  selected,  the  layout  has  been  sent 
to  the  manufacturer  for  fabrication.  Soldering  the  components  to  the  board  will 
be  the  final  step  required  to  complete  the  CFTP  development  board.  It  will  be  the 
work  of  future  researchers  to  test  and  validate  the  architecture  and  functionality 
of  the  system. 
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Vcco  (+3.3  V)  Plane 
Bottom  Signal  Trace  1 
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Vcc  (+5  V),  Bypass  Capacitors,  Signal  Trace  routing 

Figure  55.  CFTP  PCB  Layers 


11  A  Gerber  File  contains  all  the  necessary  information  for  a  PCB  manufacturer  to  construct 
the  PCB.  This  file  includes  physical  dimensions,  material  specifications,  and  net-list  information. 
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CONFIGURABLE  FAULT  TOLERANT  PROCESSOR  (CFTP) 

Figure  56.  CFTP  PCB  Final  Design 
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C.  CHAPTER  SUMMARY 

This  Chapter  brought  together  the  component  selection  process  and  the 
functional  design  of  the  CFTP  illustrating,  by  example,  the  fusion  of  design  and 
function.  The  CFTP  functionality  is  dependent  on  the  parts  selected,  which  in 
turn  were  influenced  by  the  functional  concept  of  the  CFTP.  Having  come  full 
circle,  the  CFTP  design  is  now  in  hardware  and  ready  for  the  next  phase  of  the 
system  integration  process. 
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VII.  CONCLUSIONS  AND  FOLLOW-ON  RESEARCH 


This  purpose  of  this  thesis  was  to  design,  develop,  and  deliver  the  CFTP 
flight  hardware.  While  the  final  stages  of  assembly  are  being  conducted  at  the 
time  of  publishing,  the  CFTP  flight  development  board  is  essentially  complete.  In 
concert  with  the  initial  objectives  of  this  project,  the  CFTP  has  been  designed  as 
a  single  PCB  multifunction  system,  in  order  to  demonstrate  reliable,  reconfigur- 
able  space-based  computing.  The  additional  goal  of  achieving  COTS  perform¬ 
ance  while  minimizing  cost  was  also  achieved. 

A.  OVERVIEW 

The  CFTP  hardware  design  is  another  step  in  a  program  that  will  eventu¬ 
ally  put  multiple  devices  in  various  orbits  to  demonstrate  reliable,  reconfigurable 
COTS  solutions  for  Electrical  and  Space  Systems  Engineers.  From  initial  con¬ 
cept  through  hardware  delivery,  the  CFTP  design  goals  have  remained  the 
same.  Clear  goals  and  a  well  defined  trade  space  were  essential  to  enable  the 
parts  selection  process. 

Through  this  selection  process,  RADHARD  FPGAs  were  selected  to  per¬ 
form  COTS  processor  functions.  This  is  an  interesting  mix  of  traditional 
RADHARD  ASIC  or  CPLD  devices,  which  lag  in  technology  and  speed,  and 
state-of-the-art  processing  capabilities.  In  the  case  of  the  RADHARD  FPGA,  the 
devices  certainly  lag  non-RADHARD  FPGA  technology,  but  because  of  the  re¬ 
programmable  nature  of  FPGAs,  they  can  achieve  COTS-like  performance. 

B.  CONCLUSIONS 

The  design  of  a  complex  system,  without  knowing  what  functions  it  will 
perform  in  the  future,  and  therefore  not  truly  knowing  what  the  necessary  archi¬ 
tecture  should  be  designed  to,  is  a  challenging  problem.  By  simply  maximizing 
system  flexibility  by  designing  in  reconfigurability  options,  as  well  as  selecting  the 
most  advanced  and  reliable  parts  available,  this  system  offers  the  necessary  ar¬ 
chitecture  to  meet  the  unpredictable  future  needs  of  CFTP  users  many  years 
from  now. 
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The  on-orbit  reconfiguration  concept  stands  to  provide  the  space  industry, 
and  particularly  the  military,  the  advantage  of  ensuring  that  electronic  equipment 
on-orbit  utilizes  the  most  current  algorithms  and  processors.  Continued  CFTP 
research  will  help  contribute  to  improvements  in  space  based  computing  sys¬ 
tems,  offering  system  designers  reliable  flexibility  unavailable  in  the  past. 

C.  FOLLOW-ON  RESEARCH 

The  CFTP  is  manifested  for  launch  into  LEO  orbit  on  two  satellites  in 
2006;  there  are  many  areas  for  follow  on  research  that  must  be  accomplished  for 
this  to  occur.  First  and  foremost,  the  CFTP  development  board  designed  for  this 
thesis  must  be  tested  and  evaluated  for  architectural  suitability  and  that  the  paths 
designed  are  satisfactory  for  future  needs.  Assuming  that  the  design  architecture 
is  valid,  the  qualification  boards  must  by  built  and  then  qualified  for  space.  This 
verification  process  will  include  vibration,  thermal,  vacuum,  and  radiation  analy¬ 
sis.  Finally,  the  two  flight  boards  must  be  built,  tested,  and  then  integrated  into 
the  host  satellites. 

The  existing  soft  core  microprocessor  is  the  KDLX.  While  the  TMR  con¬ 
figuration  has  been  developed,  no  programs  have  been  written  for  it.  Addition¬ 
ally,  actual  instantiation  of  the  KDLX  in  an  FPGA  has  not  yet  occurred. 

Throughout  this  thesis  IP  cores,  such  as  configuration  controllers,  were 
mentioned  as  being  essential  components  to  the  instantiated  logic  in  the  FPGAs. 
While  some  of  these  cores  exist,  many  will  have  to  be  developed,  and  all  will 
have  to  be  integrated  and  married  to  the  appropriate  hardwired  pins. 

Research  into  the  implementation  of  state-of  the-art  soft-core  processors 
for  future  implementation  is  not  required  for  launch;  however  it  has  significant 
value  for  future  applicability  of  the  CFTP.  In  addition  to  soft-core  processors,  the 
use  of  other  algorithms  for  DSP  and  data  compression  has  a  great  deal  of  value 
for  on-orbit  applications. 

Finally,  the  use  of  non-RADHARD,  BGA  FPGAs  needs  to  be  evaluated  in 
the  future. 
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APPENDIX  A:  STP  AND  SERB  DOCUMENTATION 


Appendix  A  contains  the  technical  documentation  and  agreements  be¬ 
tween  the  CFTP  and  the  Space  Test  Program,  including  the  application  to  the 
Space  Experiments  Review  Board.  Table  13  lists  the  document,  the  page  that  it 
begins  on,  and  the  number  of  pages  in  that  document.  Note  that  the  documents 
in  this  Appendix  have  retained  the  original  formatting  due  to  their  official  nature 
and  the  required  approval  process.  As  such,  the  page  numbers  in  this  Appendix 
apply  to  each  specific  document  rather  than  this  thesis  as  a  whole. 
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Space  Test  Program  Flight  Request  Executive  Summary  (DD  1721-1) 

99 
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101 
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Experiment  Requirements  Document  for  Configurable  Fault  Tolerant  Proces¬ 
sor  (CFTP)  NPS  0201 

113 

16 

Department  of  Defense  Space  Test  Program  MidSTAR-1  Mission  Require¬ 
ments  Document 

129 

29 

Technical  Requirements  Document  for  the  Midshipmen  Science  and  Technol¬ 
ogy  Advanced  Research  Mission  1  (MidSTAR-1) 

159 

38 
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SPACE  TEST  PROGRAM 
FLIGHT  REQUEST  EXECUTIVE  SUMMARY 


1.  EXPERIMENT  TITLE 

Configurable  Fault  Tolerant  Processor 


CLASSIFY  BY  DECLASSIFY  ON 

Unclassified  N/A 


2.  SHORT  TITLE/ACRONYM 

CFTP 


3.  EXPERIMENT  NUMBER  NPS-0201  |  4.  DATE  (YYYYMMDD)  2002-08-09 

5.  OBJECTIVE 

To  subject  CFTP  to  a  variety  of  radiation  fluxes  to  test  suitability  of  design  in  numerous  space  radiation  environments.  Evaluate  on-orbit,  a  triple-redundant,  fault-tolerant 
computer  design  to  mitigate  bit  errors  in  computation  by  detecting  errors  and  correcting  them  through  voting  logic.  Fly  a  low-cost,  COTS,  reconfigurable  fault  tolerant 
processor. 


6.  DESCRIPTION  -  Please  include  descriptive  website  address  if  applicable 

The  CFTP  will  provide  an  educational  tool  for  officer  students  at  NPS  in  Electrical  Engineering  and  Space  Systems  Engineering  and  Operations  curriculums.  The  CFTP 
will  use  COTS  technology  in  design  to  investigate  a  low-cost,  flexible  alternative  to  processor  hardware  architecture,  using  Field  Programmable  Gate  Arrays  (FPGA)  as  a 
basis  for  a  system  on  a  chip 

WEB  SITE:  http://www.nps.navy.mil/CFTP 

7.  RELEVANCE  TO  SPECIFIC  DOD  REQUIREMENTS 

-DOD  and  the  National  Reconnaissance  Office  have  a  need  for  many  space-based  missions,  such  as  reconnaissance  and  communications.  All  of  these  missions  require 
reliable  computing  to  perform  the  necessary  attitude  control,  power  management,  communication,  data  handling,  and  payload  management.  Reconfigurability  of  the 
processor  allows  adaptation  of  the  satellite  to  new  missions  and  the  use  of  improved  algorithms. 


8.  REQUIREMENTS  SUMMARY 


a.  REQUESTED  STP  SERVICES 
3  LAUNCH  SERVICES  3  OPERATIONS 

3  LAUNCH  INTEGRATION  3  SPACECRAFT/EXPERIMENT  INTEGRATION 

□  SPACECRAFT  DEVELOPMENT  □  OTHER  (Specify): 

3  data  DISTRIBUTION _ 

d.  FLIGHT  MODE  (1= Preferred ,  2=Acceptable,  Blank=Unacceptable) 


1  FREE-FLYER  SI 

f.  DIMENSIONS  (cm) 

12  X  17.5 


j.  STABILIZATION  TYPE 
N/A 


OTHER  (Specify) 

g.  MASS  (kg) 

1 


h.  VOLUME  (cc) 
816 


k.  ORBIT  REQUIREMENTS  (km) 
APOGEE  35000 


b.  NUMBER  OF  FLIGHTS 

REQUESTED/REQUIRED  TO 
MEET  OBJECTIVES 


e.  POWER  (W) 
STAND-BY 
.5  (EST) 


NOMINAL 
4  (EST) 


c.  FLIGHT  DURATION 
REQUIRED 


365  days 


MAXIMUM 
7  (EST) 


i.  HARDWARE  FLIGHT  READY  DATE  (YYYYMMDD) 
2004-07-01 


I.  INCLINATION  (Degrees) 


m.  OTHER  REQUIREMENTS 

Multiple  orbits  required:  1.  GTO  or  Molniya,  2.  LEO  low  inclination,  3.  LEO  mid  inclination,  4.  LEO  high  inclination 


9.  PROGRAM  SUMMARY _ 

a.  FUNDING  BREAKDOWN  ($  Needed/$  Secured) 


NRO/SSPO 


PRIOR  FY  FUNDS 

15000/15000 


CURRENT  FY  FUNDS 

20000/20000 


51000/51000 


FUTURE  FY  FUNDS 


TOTAL  COST 

75000/35000 


151000/51000 


b.  DESIGN/FABRICATION  STATUS 

Design 

10.  DoD  DEPARTMENTAL  APPROVAL 

a.  APPROVING  OFFICIAL  (Last  Name,  First,  Middle  Initial) 


c.  CONTRACTOR 

N/A 


b.  OFFICE  SYMBOL 


c.  POSITION 


d.  MAILING  ADDRESS  (Street,  Apt/Suite  No.,  City,  State,  ZIP  Code)  e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 

COMMERCIAL 


f.  SIGNATURE 


g.  EMAIL 


h.  PRINCIPAL  INVESTIGATOR  (Last  Name,  First,  Middle  Initial) 
Loomis,  Flercshel  FI 


i.  OFFICE  SYMBOL 

NAVPGSCOL 


j.  POSITION 

Professor,  Department  of  Elec  &  Comp  Eng 


k.  MAILING  ADDRESS  (Street,  Apt/Suite  No.,  City,  State,  ZIP  Code) 
111  Dyer  Rd  Code  SP 
Monterey,  CA  93943 


l.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 

COMMERCIAL  (831 )  656  321 4 

m.  SIGNATURE 


DSN  756-3214 

n.  EMAIL 

FILoomis@nps.navy.mil 


DD  FORM  1791-1 
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SPACE  TEST  PROGRAM 
FLIGHT  REQUEST 


DATE  (YYYYMMDD) 

CLASSIFIED  BY 

2002-10-11 

UNCLASSIFIED 

DECLASSIFY  ON 

N/A 


PART  I  -  REQUEST  FOR  SPACEFLIGHT 


1.  EXPERIMENT  TITLE 

Configurable  Fault  Tolerant  Processor 


2.  SHORT  TITLE/ACRONYM 

CFTP 


3.  EXPERIMENT  NUMBER 

NPS-0201 


6.  PROJECT  OFFICE 

Naval  Postgraduate  School 


4.  PROJECT  NUMBER 

NPS-0201 


7.  MANAGEMENT  OFFICE 

Naval  Postgraduate  School 


5.  PROGRAM  ELEMENT  NUMBER 

SP 


8.  SPONSOR 

Naval  Postgraduate  School 


9.  PRINCIPAL  INVESTIGATOR  (REQUIRED) 


a.  NAME  (Last,  First,  Middle  Initial) 
Loomis,  Flerschel  FI 


b.  OFFICE  SYMBOL 

NAVPGSCOL 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 
COMMERCIAL  I  DSN  | 

(831)656-3214  756-3214 


PAGER/MOBILE 

N/A 


c.  POSITION 

Professor,  Department  of  Electrical  and 
Computer  Engineering 

f.  SIGNATURE 


d.  EMAIL 

HLoomis@nps.navy.mil 


g.  DATE  (YYYYMMDD) 


10.  PROJECT  OFFICE  APPROVAL 


a.  NAME  (Last,  First,  Middle  Initial) 
Loomis,  Flerschel  FI 


b.  OFFICE  SYMBOL 

NAVPGSCOL 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 
COMMERCIAL  I  DSN 

(831)656-3214  756-3214 


c.  POSITION 

Professor,  Department  of  Electrical  and 
Computer  Engineering 

f.  SIGNATURE 


d.  EMAIL 

HLoomis@nps.  navy,  mil 


g.  DATE  (YYYYMMDD) 


1 1 .  MANAGEMENT  OFFICE  APPROVAL 


a.  NAME  (Last,  First,  Middle  Initial) 
Powers,  John  P. 


b.  OFFICE  SYMBOL 

NAVPGSCOL 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 
COMMERCIAL  I  DSN 

(831)656-2081  756-2081 


c.  POSITION 

Chairman  and  Distinguished  Professor, 
Department  of  Electrical  and  Computer 
Engineering _ 

f.  SIGNATURE 


d.  EMAIL 

jpowers@nps.navy.mil 


g.  DATE  (YYYYMMDD) 


12.  SPONSOR  APPROVAL  (REQUIRED) 


a.  NAME  (Last,  First,  Middle  Initial) 
Powers,  John  P. 


b.  OFFICE  SYMBOL 

NAVPGSCOL 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 
COMMERCIAL  I  DSN 

(831)656-2081  756-2081 


c.  POSITION 

Chairman  and  Distinguished  Professor, 
Department  of  Electrical  and  Computer 
Engineering _ 

f.  SIGNATURE 


d.  EMAIL 

jpowers@nps.navy.mil 


g.  DATE  (YYYYMMDD) 


13.  INTERMEDIATE  ACTIVITY 


a.  NAME  (Last,  First,  Middle  Initial) 


b.  OFFICE  SYMBOL 


c.  POSITION 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 

COMMERCIAL  I  DSN 


f.  SIGNATURE 


g.  DATE  (YYYYMMDD) 


14.  DoD  DEPARTMENTAL  APPROVAL  (REQUIRED) 


a.  NAME  (Last,  First,  Middle  Initial)  b.  OFFICE  SYMBOL 


c.  POSITION 


e.  TELEPHONE  NUMBER(S)  (Include  Area  Code) 

COMMERCIAL  I  DSN 


f.  SIGNATURE 


g.  DATE  (YYYYMMDD) 


DD  FORM  1721 


Page  1  of  11 


EXPERIMENT  TITLE 

Configurable  Fault  Tolerant  Processor 

15.  REQUESTED  STP  SERVICES 

M  LAUNCH  SERVICES  (Complete  Item  15b)  £<]  OPERATIONS 

Kl  LAUNCH  INTEGRATION  £<]  SPACECRAFT/EXPERIMENT  INTEGRATION 

n  SPACECRAFT  DEVELOPMENT  Q  OTHER  (Specify): 

IEI  DATA  distribution 

a.  NUMBER  OF  FLIGHTS  REQUESTED/REQUIRED  TO  MEET  OBJECTIVE:  4/1 

b.  DESIRED  FLIGHT  MODE  (1 =Pref erred,  2=Acceptable,  Blank=  Unacceptable) 

SHUTTLE  (Complete  Section  IIIA)  2  ISS  (Complete  Section  IIIA)  1  FREEFLYER  (Complete  Section  IIIB)  OTHER  (Specify): 

16.  OBJECTIVE 

1 .  To  subject  CFTP  to  a  variety  of  radiation  fluxes  to  test  suitability  of  design  in  numerous  space  radiation  environments. 

2.  Evaluate  on-orbit,  a  triple-redundant,  fault-tolerant  computer  design  to  mitigate  bit  errors  in  computation  by  detecting  errors  and  correcting  them  through  voting  logic. 

3.  Fly  a  low-cost,  COTS,  reconfigurable  fault  tolerant  processor. 

4.  To  provide  a  hands-on  educational  tool  for  officer  students  at  NPS  in  the  design,  development,  test,  and  on-orbit  operations  of  processor  architecture. 

5.  To  demonstrate  commercial,  off-the-shelf  technology  applied  to  spacecraft  architecture  as  a  means  of  decreasing  development  time,  decreasing  costs,  and  increasing 
reliability  in  hardware  development  and  implementation. 

6.  Demonstrate  applicability  of  reconfigurable,  reliable,  fault  tolerant  processing  architectures  to  space  based  applications. 

7.  Demonstrate  the  value  of  reconfigurable  processors  as  cost  effective  flexible  alternatives  to  custom  integrated  circuit  architectures  across  the  spectrum  of  military/DoD 
applications. 


17.  RELEVANCE  TO  SPECIFIC  DOD  REQUIREMENTS 

-CFTP  is  a  flexible  and  cost-effective  means  to  address  numerous  processing  requirements,  and  addresses  the  requirement  of  shorter  development  time  for  satellites,  in 
accordance  with  the  USSPC  LRP. 

-CFTP  addresses  the  requirement  in  Ch  8  of  the  DTAP  of  capitalizing  on  radiation  tolerant  COTS  technology. 

-AFSPC  SMP  Ch4  requirement  #59:  Reliable  General  Purpose  Vehicle  Fleet.  CFTP  can  satisfy  the  general-purpose  aspect  with  its  ability  to  be  reconfigured  as  needed  to 
support  multi-mission  tasking. 

-  The  CFTP  supports  the  education  and  training  of  officer  personnel  in  order  to  maintain  a  foundation  of  high-quality  people  and  innovative  leadership  within  the  Naval  Space 
Cadre. 


18.  DESCRIPTION  -  Please  include  descriptive  website  address  if  applicable. 

The  CFTP  will  provide  an  educational  tool  for  officer  students  at  NPS  in  Electrical  Engineering  and  Space  Systems  Engineering  and  Operations  curriculums.  The  CFTP  will  use 
COTS  technology  in  design  to  investigate  a  low-cost,  flexible  alternative  to  processor  hardware  architecture,  using  Field  Programmable  Gate  Arrays  (FPGA)  as  a  basis  for  a 
system  on  a  chip.  Increasing  the  flexibility  of  the  processor  architecture  will  serve  as  a  means  of  decreasing  development  time  while  allowing  software  development  and 
component  integration  to  commence  at  the  earliest  stages  of  development,  with  the  expectation  that  the  processor  will  be  configured  to  support  any  design  constraints. 

Exploiting  triple  modular  redundancy  to  mitigate  single  event  transients  in  various  radiation  environments  enables  the  system  on  a  chip  to  continue  normal  functional  routine 
without  requiring  a  reset  and  commensurate  loss  of  data,  normally  associated  with  a  return  to  a  trusted  state.  Additionally,  the  flexibility  of  a  configurable  processor,  based  on 
COTS  FPGA  technology,  will  enable  in  orbit  upgrades,  reconfigurations,  and  modifications  to  the  onboard  architecture  in  order  to  support  dynamic  mission  requirements. 

WEB  SITE:  http://www.nps.navy.mil/CFTP 


19.  BACKGROUND 

The  Small  Satellite  Design  Studies  program  at  NPS  has  been  ongoing  for  over  a  decade.  The  objective  is  to  provide  hands-on  education  for  officer  students  in  the  Electrical 
Engineering  and  Space  Systems  Curricula.  This  program  offers  an  excellent  means  of  teaching  officer  students  and  exposing  them  to  the  many  technical,  managerial,  and 
operational  challenges  in  the  full  life  cycle  of  a  space  system.  The  success  can  be  gauged  by  the  1998  launch  and  current  operation  of  the  PANSAT  small  satellite,  which 
produced  more  than  50  Master's  theses  and  continues  to  provide  a  rich  teaching  tool.  PANSAT  is  a  small,  tumbling  (no  attitude  control),  digital  communications  satellite. 
COTS  FPGA  technology  provides  a  mechanism  for  scalable,  configurable  processing  architectures  with  low  overhead,  and  rapid  development  cycles,  allowing  system 
designers  to  use  more  sophisticated  and  powerful  applications  and  tools  in  their  hardware  and  software  development.  FPGA  technology  also  allows  on  orbit 
modifications/upgrades  to  system  architecture. 


EXPERIMENT  NUMBER 

NPS-0201 


DATE  (YYYYMMDD) 
2002-10-11 
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DATE  (YYYYMMDD) 

EXPERIMENT  TITLE 

EXPERIMENT  NUMBER 

2002-10-11 

Configurable  Fault  Tolerant  Processor 

NPS-0201 

20.  DESCRIPTIVE  GRAPHIC 


21.  ALTERNATIVES  TO  SPACEFLIGHT 

The  CFTP  is  largely  an  electrical  engineering  experiment.  Spaceflight,  particularly  in  different  orbits,  offers  the  long-term  environment  for  evaluation;  actually  combining  many 
environments,  such  as  launch  vibro-acoustic,  and  space  thermal,  vacuum,  radiation,  and  solar  energy  inputs  that  would  not  be  cost-effective  to  recreate  in  a  laboratory 
environment.  There  is  no  alternative  in  the  educational  process  to  actually  doing  that  which  is  trying  to  be  taught. 


22.  EXPERIMENT  UNIQUENESS  -  Explain  how  the  proposed  experiment  differs  from  and/or  is  complementary  to  other  similar  efforts.  Indicate  if  a 
competition  is  pending  and  when  award  is  expected. 

CFTP  demonstrates  a  combined  hardware  and  software,  COTS  solution  to  address  software  reliability,  maintainability,  and  timeliness. 

CFTP  will  be  the  first  to  demonstrate  configurability  of  a  processor  while  on  orbit. 

CFTP  will  be  the  first  to  utilize  COTS  available  FPGA  technology,  reliable  system  on  a  chip  as  alternative  to  radhard  processors. 

CFTP  is  unique  in  that  it  directly  addresses  maintaining  the  caliber  of  highly-quality  people  for  Navy  space  needs  and  its  professional  cadre. 


23.  FOLLOW-ON  PLANS 

CFTP  will  be  the  first  in  a  series  of  FPGA  based  systems  on  a  chip  designed  for  DoD  applications. 

The  Small  Satellite  Design  Studies  program  at  NPS  marries  the  educational  goals  with  a  research  program  in  satellite  technology  to  introduce  higher  capability  and  greater 
reliability  in  small  satellites.  Research  will  continue  on  the  use  of  configurable  processors  to  support  the  needs  for  fault-tolerant  processing  in  space. 
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DATE  (YYYYMMDD) 

2002-10-11 

EXPERIMENT  TITLE 

Configurable  Fault  Tolerant  Processor 

EXPERIMENT  NUMBER 

NPS-0201 

PART  II  -  PROGRAM/SECURITY  INFORMATION 

24.  HARDWARE  STATUS 

□  FLIGHT  READY 

□  UNDER  CONSTRUCTION 

□  BREADBOARD 


25.  DESIGN-FREEZE  DATE 

2003/01 


27.  FUNDING  BREAKDOWN  ($  Needed /$  Secured) 


a.  SOURCE  b.  PRIOR  FY  FUNDS 


NRO/LSPO  35,000  /35,000 


NRO/SSPO 


[Xj  DESIGN 
□  CONCEPT 


26.  DELIVERY  DATE 

2003/03 


c.  CURRENT  FY  FUNDS 


d.  FUTURE  FY  FUNDS 


e.  TOTAL  COST 


75,000 


151,000 


f.  DATA  PROCESSING  AND  DISSEMINATION  FULLY  FUNDED?  (Required per  AFI-1 0-1 202(1))  □  NO  IXI  YES 


g.  ON  ORBIT  OPERATIONS  BEYOND  FIRST  YEAR  FULLY  FUNDED?  (STP  only  pays  for  the  first  year  of  on  orbit  operations  per  AFi  10-1202(1)) 

□  NO  □  YES  |XI  NOT  APPLICABLE 


h.  REMARKS 

Project  reimbursably  funded  by  the  NRO. 


28.  BUDGET/PROGRAM  AUTHORIZATION  NUMBER 

N/A 


29.  CONTRACTOR  RESPONSIBILITY 

N/A 


30.  LOCATION  OF  CONTRACT  WORK 

N/A 


31.  CONTRACT  NO. 

N/A 


32.  PLANNED  CONTRACT  OBLIGATION  DATE 

N/A 


33.  PLAN  FOR  DATA  PROCESSING  AND  DISSEMINATION  OF  RESULTS 

Raw  data  fusion  will  occur  at  NPS.  Dissemination  of  results  through  publication  of  Master's  Theses  and  technical  papers. 


34.  SECURITY  INFORMATION  (State  highest  levels) 


a.  EXPERIMENT  OBJECTIVES 


e.  FLIGHT  SOFTWARE 
U 


b.  TIMELINE 

U 

f.  EXPERIMENT  DATA 


i.  IS  RAW  DATA  CLASSIFIED?  (ISS/Shuttle  cannot  provide) 

IEI  NO  □  YES 

k.  OTHER  CLASSIFIED  ITEMS 
N/A 


c.  EXTERNAL  VIEW 


d.  FLIGHT  HARDWARE 


g.  RAW  DATA  h.  INTERNAL  FEATURES 

_ Lu _ 

j.  ENCRYPTION  OF  RAW  DATA  REQUIRED?  (ISS/Shuttle  cannot  provide) 
EH  NO  □  YES 


I.  ARE  ANY  TECHNOLOGIES  USED  IN  THIS  EXPERIMENT  LISTED  IN  THE  MILITARY  CRITICAL  TECHNOLOGIES  LIST  (MCTL)  OR  THE  US  MUNITIONS  LISTS? 
□  no  EH  YES 

IF  YES,  ARE  THEY  CONTROLLED  THROUGH  THE  INTERNATIONAL  TRAFFIC  IN  ARMS  REGULATION  (ITAR)?  EH  NO  EH  YES 


m.  ARE  FOREIGN  NATIONALS  INVOLVED  WITH  THIS  EXPERIMENT? 


NO  \2S]  YES 
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DATE  (YYYYMMDD) 

EXPERIMENT  TITLE 

EXPERIMENT  NUMBER 

2002-10-11 

Configurable  Fault  Tolerant  Processor 

NPS-0201 

PART  IMA  -  TECHNICAL  DETAILS: 

SPACE  SHUTTLE/ISS 

1  35.  FLIGHT  OPTIONS  1 

a.  SHUTTLE  FLIGHT  OPTIONS  b.  ISS  FLIGHT  OPTIONS 

□  LOCKER  □  HITCHHIKER  □  EXPRESS  PALLET  (UNPRESSURIZED)  □  WINDOW  OBSERVATION  RACK 

□  SPARTAN  □  CROSS-BAY  m  ^  FACILITY  (PRESSURIZED) 

□  G.A.S.  CAN  □  OTHER  (Specify):  □  EXPRESS  RACK  (PRESSURIZED)  3  OTHER  (Specify):  See  46g 

36.  STANDARD  SUPPORT  HARDWARE  DESIRED 

□  LOCKER 

□  PAYLOAD  EJECTION  SYSTEM/SHUTTLE  HITCHHIKER  EJECTION  LAUNCH  SYSTEM 

□  EXPRESS  PALLET  ADAPTER  PLATE 

1^1  OTHER  (Specify):  Bus  interface  and  card  mounting 

37.  MASS  (kg)  38.  PHYSICAL  39.  TOTAL  VOLUME  (cc)  40.  EXTENSIONS  BEYOND  PAYLOAD  BAY 

DIMENSIONS  (cm)  816  ENVELOPE? 

a.  TOTAL  PAYLOAD  b.  EXPENDABLES  12X17.5X4 

io  IXIno  |_|yes 

41.  POWER  (W)  42.  TYPICAL  DUTY  CYCLE  (%  of  operation) 

a.  STAND-BY  b.  NOMINAL  c.  MAX.  POWER  a.  STAND-BY  b.  NOMINAL  c.  MAX.  POWER 

.5  (EST)  4  (EST)  7  (EST)  70  (EST)  25  (EST)  5  (EST) 

43.  MAXIMUM  DUTY  CYCLE  (%  of  operation) _ 44.  MISSION  DURATION  (Days) 

a.  STAND-BY  b.  NOMINAL  c.  MAX.  POWER  a.  MINIMUM  b.  NOMINAL  c.  MAXIMUM 

40  50  10  100  365 

45.  FLIGHT  DATE  (Quarter,  Fiscal  Year)  _ _ 

a.  EARLIEST  b.  PREFERRED  c.  LATEST  d.  RATIONALE 

Q4,  2004  Q1 , 2005  OPEN  Design  and  construction  timeline  of  CFTP. 


46.  ORBITAL  PARAMETERS _ 

a.  NOMINAL  SHUTTLE  PARAMETERS  (193  -  604  km,  28.4  -  57°)  ACCEPTABLE?  □  NO  IKI  YES 


g.  REMARKS 

Extended  duration  test  on  ISS  with  payload  mounted  external  to  pressurized  bays  would  provide  meaningful  data  and  satisfy  LEO,  mid  inclination  requirement.. 


|  47.  ORIENTATION  REQUIREMENTS  (Comment  where  applicable)  | 

a.  ISS  NOMINAL  (+/- 15°  roll/yaw,  -10  to  +20°  pitch)  ACCEPTABLE? 

□  NO 

13  YES 

b.  X-AXIS  c.  Y-AXIS 

d.  Z-AXIS 

e.  OTHER  REQUIREMENTS 

-Data  downlink  required. 

-CFTP  positioned  to  receive  exposure  to  sun  and  radiaiton 
-Minimum  shielding 

f.  VIEWING  REQUIREMENTS 

□  NADIR 

□  ZENITH 

□  RAM 

□  WAKE 

□  WINDOW  (NADIR) 

□  OTHER  (Specify): 

□  NOT  APPLICABLE 

1  g.  REMARKS  j 

DD  FORM  1721 


Page  5  of  11 
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EXPERIMENT  TITLE 

Configurable  Fault  Tolerant  Processor 


EXPERIMENT  NUMBER 

NPS-0201 


48.  STABILIZATION  REQUIREMENTS  (Pointing  Accuracy  (degrees). /pointing  knowledge  (degrees/axis)) 


a.  ISS  NOMINAL  (control:  3.5  deg/axis/orbit;  rate:  0.02  deg/sec/axis;  knowledge:  3  deg/axis)  ACCEPTABLE?  EH  NO  EH  YES 


b.  LINE-OF-SITE  c.  ROLL  ABOUT  LINE-OF-SITE  d.  JITTER  OR  DRIFT  CONTROL 


e.  EXPERIMENT  PROVIDED  POINTER 

N/A 


49.  MAJOR  MOVEMENTS 


a.  TRACK 

None. 


c.  OTHER  MOTIONS 

None. 


50.  ASTRONAUT  PARTICIPATION 


a.  REQUIRED? 


M  NO  □  YES 


d.  DESCRIPTION  OF  ASTRONAUT  DUTIES 


b.  FUNCTION 

□  MONITORING 

□  COMMAND  AND  CONTROL 

□  ANALYSIS 

□  OTHER  (Specify): 

c.  NON  U.S.  ASTRONAUT  PARTICIPATION  ACCEPTABLE? 


51.  GROUND  SUPPORT  REQUIREMENTS  DURING  FLIGHT 

The  ability  to  communicate  with  the  CFTP  board  during  flight,  uploading  reconfiguration  commands  and  downloading  performance  data. 


52.  EPHEMERIS  REQUIREMENTS 

Only  approximate  position  versus  time  data  required  to  be  able  to  determine  radiation  flux. 
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53.  TELEMETRY  AND  DATA  HANDLING _ 

a.  DATA  STORAGE  (Bits  per  orbit)  I  b.  DATA  OUTPUT  RATE  (bps) 


c.  COMMAND  REQUIREMENTS 


□  REAL-TIME  3  NEAR  REAL-TIME  □  NOT  REQUIRED 


d.  SPECIAL  REQUIREMENTS 

Configuration  upload  -  daily:  1  Mbyte  which  requires  S-Band  Single  Access  Mode  with  transfer  rate  of  1  Mbps  or  greater. 


e.  REMARKS 

Data  generation  rate  on  average  approximately  1 ,000,000  bytes/week. 


54.  EXPERIMENT  COMPLEMENT/PACKAGE  DATA 


b.  DIMENSIONS  STOWED  (cm)  c.  DIMENSIONS  DEPLOYED  (cm)  d.  MASS  (kg)  e.  EJECTED?  f.  RECOVERY? 

12x17.5x4  N/A  1  NO  NO 


g.  OTHER  PERTINENT  DATA 

TBD 


h.  DESIGN  DRAWING  SPECIFICATION  STATUS 

Design 


55.  CONTAMINATION  CONTROL  REQUIREMENTS? 

3  NO  □  YES  (If  yes,  explain ): 

56.  SPACE  SHUTTLE/ISS  SAFETY 


a.  POSSIBLE  HAZARDS 


RADIOACTIVE  DEVICES 


HAZARDOUS  MATERIALS 


|  NO  □  YES  (If  yes):  MATERIAL(S): 
|  NO  □  YES  (If  yes):  MATERIAL(S): 

|  NO  □  YES  (If  yes,  specify): 


STRENGTH  (Ci): 


b.  DESCRIBE  SAFETY  COORDINATION  ACTIVITIES  WITH  NASA  TO  DATE  (If  any) 

NONE 


c.  OTHER  REQUIREMENTS 

N/A 
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_ PART  NIB  ■  TECHNICAL  DETAILS:  FREE-FLYER  MODE 

57.  EXPERIMENT  CLASS 


[X]  EXPERIMENT  ONLY  Q  COMPLETE  SPACECRAFT  Q  PIGGYBACK  PAYLOAD  PREFERRED  (Specify  Host): 


58.  MASS  (kg) 

59.  PHYSICAL  DIMENSIONS  (cm) 

a.  TOTAL  PAYLOAD  b.  EXPENDABLES 

1  0 

c.  SPACECRAFT  (If provided) 

0  12x17.5x4 

60.  TOTAL  VOLUME  (cc)  61.  POWER  (W) 

62.  TYPICAL  DUTY  CYCLE  (%  of  operation) 

a.  STAND-BY  b.  NOMINAL 

816  0.5  (EST)  4  (EST) 

c.  MAX.  POWER  a.  STAND-BY  b.  NOMINAL  c.  MAX.  POWER 

7  (EST)  70  (EST)  25  (EST)  5  (EST) 

63.  MAXIMUM  DUTY  CYCLE  (%  of  operation) 

64.  MISSION  DURATION  (Months) 

a.  STAND-BY  b.  NOMINAL  c.  MAX.  POWER 

40  (EST)  50  (EST)  10  (EST) 

a.  MINIMUM  b.  NOMINAL  c.  MAXIMUM 

10  30 

d.  RATIONALE 

Design  and  contruction  timeline  for  CFTP. 


66.  ORBITAL  PARAMETERS _ _ _ 

a.  APOGEE  (km)  b.  PERIGEE  (km)  c.  INCLINATION  (Degrees) 

35000  +2000  -4000  500  +400  -100  40  +15  -15 

d.  RATIONALE 

Orbit  should  expose  payload  to  sufficient  radiation  to  cause  SEUs,  and  should  provide  a  variety  of  flux. 

e.  ALTERNATE  ORBITS  (Acceptable,  if  primary  orbit  is  unavailable) 

Multiple  orbits  required:  1 .  GTO  or  Molniya,  2.  LEO  low  inclination,  3.  LEO  mid  inclination,  4.  LEO  high  inclination 


f.  AXIS/ORBIT  PLANE  RESTRICTIONS 


67.  STABILIZATION  REQUIREMENTS  (Pointing  accuracy  (degrees)/pointing  knowledge  (degrees/axis)) 


a.  STABILIZATION  TYPE 

b.  ROLL 

c.  PITCH 

□  SPIN  (If  yes):  SPIN  RATE  (rpm): 

/ 

/ 

IEI  ANY 

□  3-AXIS 

□  OTHER  (Specify): 

d.  YAW 

e.  JITTER  OR  DRIFT 

f.  OTHER  REQUIREMENTS 

Require  minimum  shielding  to  allow  for  maximum  exposre  to  radiation. 

g.  REMARKS 
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68.  MAJOR  MOVEMENTS  (Explain  and  provide  rates) 

a.  TRACK 

None 


b.  SLEW 

None 


c.  OTHER  MOTIONS 

None 


d.  REMARKS 


69.  GROUND  SUPPORT  REQUIREMENTS  DURING  FLIGHT 

The  ability  to  communicate  with  the  CFTP  board  during  flight. 


70.  EPHEMERIS  REQUIREMENTS 

Only  approximate  position  versus  time  data  required  to  be  able  to  determine  radiation  flux. 


71.  TELEMETRY  &  DATA  HANDLING 


a.  DATA  STORAGE  (Bits  per  day) 

b.  DATA  OUTPUT  RATE  TO  SPACECRAFT  (bps) 

c.  REAL-TIME  DATA  REQUIREMENT  (bps) 

N/A 

NOMINAL 

MAXIMUM 

£<]  REAL-TIME  DATA  NOT  REQUIRED 

N/A 

N/A 

P]  REAL-TIME  DATA  REQUIRED  AT  RATE: 

d.  SPECIAL  REQUIREMENTS 

Data  output  rate  to  telemetry  -  Nominal  9600  bps,  total  1  Mbyte/week 


e.  REMARKS 

Configuration  upload  -  daily:  1  Mbyte  which  requires  S-Band  Single  Access  Mode  with  transfer  rate  of  1  Mbps  or  greater. 


72.  COMMANDS 

a.  NUMBER  OF  POWER  COMMANDS  b.  NUMBER  OF  SERIAL/DIGITAL  COMMANDS 

3  25 


c.  NUMBER  OF  DISCRETE  COMMANDS  d.  MAGNITUDE  COMMAND  WORD  SIZE  (Bits)  e.  COMMAND  STORAGE 

TBD  40  None 
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73.  POSSIBLE  HAZARDS 

RADIOACTIVE  DEVICES 

^  NO 

EH  YES  (If yes):  MATERIAL(S): 

STRENGTH  (Ci): 

HAZARDOUS  MATERIALS 

^  NO 

EH  YES  (If  yes):  MATERIAL(S): 

OTHER 

^  NO 

EH  YES  (If  yes,  specify): 

74.  CONTAMINATION  CONTROL  REQUIREMENTS? 

EH  NO  EH  YES  (If  yes,  explain): 

75.  EXPERIMENT  COMPLEMENT/PACKAGE  DATA 

a.  ITEM 

b.  DIMENSIONS  STOWED  (cm) 

c.  DIMENSIONS  DEPLOYED  (cm) 

d.  MASS  (kg) 

e.  OTHER  PERTINENT  DATA 

TBD 


f.  EXPERIMENT  EQUIPMENT  MOUNTING  RESTRICTIONS 

Modified  PCI  04  bus  used  to  connect  with  satellite  bus.  Final  pinout  design  incomplete.  See  attached  schematic  for  mounting  requirements. 


g.  DESIGN  DRAWING  SPECIFICATION  STATUS 

Design 


76.  OTHER  REQUIREMENTS 
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1.  SCOPE 

This  document  contains  the  specific  requirements  of  the  Configurable  Fault  Tolerant  Processor 
(CFTP).  It  provides  experiment  requirements  in  the  following  areas:  physical  and  functional 
interfaces,  spacecraft  integration  and  test,  launch  systems,  and  on-orbit  flight  operations. 

2.  EXPERIMENT  OVERVIEW 

2.1.  Experiment  Description 

The  CFTP  provides  an  educational  tool  for  officer  students  at  NPS  in  Electrical 
Engineering,  and  Space  Systems  Engineering  and  Space  Systems  curricula.  The  CFTP 
uses  a  Commercial  Off-The-Shelf  (COTS)  technology  design  to  investigate  a  low-cost, 
flexible  alternative  to  processor  hardware  architecture,  using  Field  Programmable  Gate 
Arrays  (FPGA)  as  a  basis  for  a  system  on  a  chip.  Increasing  the  flexibility  of  the 
processor  architecture  will  decrease  development  time  while  allowing  software 
development  and  component  integration  to  commence  at  the  earliest  stages  of 
development,  with  the  expectation  that  the  processor  will  be  configured  to  support  any 
design  constraints. 

Exploiting  Triple  Modular  Redundancy  (TMR)  to  mitigate  single-event  transients  in 
various  radiation  environments  enables  the  system  on  a  chip  to  continue  normal  operation 
without  requiring  a  reset  and  commensurate  loss  of  data  normally  associated  with  a 
return  to  a  trusted  state.  Additionally,  the  flexibility  of  a  configurable  processor,  based 
on  COTS  FPGA  technology,  will  enable  on-orbit  upgrades,  reconfigurations,  and 
modifications  to  the  architecture  in  order  to  support  dynamic  mission  requirements. 

While  this  document  details  the  experiment  requirements  for  the  current  design  of  the 
CFTP,  it  is  important  to  understand  that  the  CFTP  design  can  be  modified  to  meet  many 
of  the  design  parameters  of  the  spacecraft  and  launch  vehicle  (eg.  electrical  interface 
requirements,  environmental  requirements,  etc. . .).  The  intent  of  this  document  is  to 
provide  a  foundation  upon  which  begin  a  dialogue  between  the  spacecraft  and  launch 
vehicle  contractors  and  the  CFTP  project  team. 

2.2.  Experiment  Objectives 

1.  To  provide  a  hands-on  educational  tool  for  officer  students  at  the  Naval  Postgraduate 
School  (NPS)  in  the  design,  development,  testing  and  on-orbit  operations  of  a 
configurable-processor  architecture. 

2.  To  subject  the  CFTP  experiment  to  a  variety  of  radiation  fluxes  to  test  suitability  of 
design  in  numerous  space  radiation  environments. 

3.  Evaluate  on  orbit,  a  triple-redundant,  fault-tolerant,  reconfigurable  computer  design 
which  mitigates  bit  errors  in  computation  by  detecting  errors  and  correcting  them  through 
voting  logic. 

4.  To  demonstrate  COTS  technology  applied  to  spacecraft  architecture  as  a  means  of 
decreasing  development  time,  decreasing  costs,  and  increasing  reliability  in  hardware 
development  and  implementation. 

5.  To  demonstrate  applicability  of  reconfigurable,  reliable,  fault  tolerant  processing 
architectures  to  space  based  applications. 
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6.  To  demonstrate  the  value  of  reconfigurable  processors  as  cost  effective  flexible 
alternatives  to  custom  integrated  circuit  architectures  across  the  spectrum  of 
military/DoD  applications. 

2.3.  Operational  Concept 

The  purpose  of  the  space  flight  portion  of  this  project  is  to  accumulate  as  much 
operational  experience  and  flight  data  as  possible. 

It  is  desired  to  operate  the  CFTP  continuously  for  one  year,  but  the  experiment  can 
support  periodic  operation,  reduced  power  or  “sleep”  modes  as  well.  Data  download 
volume  is  TBD,  but  may  be  on  the  order  of  1M  bit  per  pass.  Minimum  data  upload 
required  for  configuration  and  operating  software  is  576k  bytes  but  could  be  as  high  as 
several  Mega-bytes  which  could  be  loaded  on  multiple  passes. 

Specific  interaction  with  and  requirements  for  the  SC  are  TBD  (provide  signal  to  initiate 
self-test,  etc...). 

The  year  of  operation  is  broken  down  into  four  main  phases,  which  are  also  directly  tied 
to  mission  success. 

Phase  I 

With  initial  softcore  configuration  loaded  and  tested  on  the  ground,  conduct  the 
following  on-orbit  operations: 

□  Perform  self-tests 

□  Establish  data  transfer  path 


Phase  II 

After  initial  on-orbit  tests  (Phase  I),  upload  and  reconfigure  with  the  TMR  softcore 
through  the  spacecraft  uplink. 

Phase  III 

With  TMR  softcore  loaded,  conduct  the  following  operations: 

□  Detect  and  correct  for  Single  Event  Upsets  (SEU) 

□  Perform  Benchmark  tests 

□  Report  error  frequencies  and  types  and  Benchmark  results  via  status 
reports  downloaded  through  the  spacecraft  downlink. 


Phase  IV 

Reconfigure  the  CFTP  experiment  as  an  on-orbit  resource  to  process  data  from  other 
experiments  or  host  systems  (Note  however,  that  the  requirements  in  this  ERD  are  only 
those  for  the  CFTP  as  a  stand-alone  experiment  and  do  not  reflect  any  additional 
interfaces  required  for  this  additional  concept  as  no  specific  additional  reconfigurations 
have  been  identified  at  this  time). 

2.4.  Orbit  Requirements 

One  of  the  main  objectives  of  the  CFTP  experiment  is  to  subject  it  to  a  variety  of 
radiation  fluxes.  Because  higher  orbits  provide  a  much  greater  exposure  to  radiation 
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fluxes  and  therefore  an  increased  probability  of  SEUs,  these  orbits  would  also  supply  a 
larger  collection  of  data  with  which  to  evaluate  the  suitability  of  our  design.  While  many 
of  our  requirements  can  be  met  with  LEO  orbits,  orbits  which  pass  through  these  high 
radiation  environments  such  as  GTO,  Molniya,  or  MEO  orbits  are  preferred.  If  multiple 
rides  are  available,  a  variety  of  orbits  is  desired. 

Order  of  preference  is:  1.  GTO  or  Molniya,  2.  MEO,  3.  LEO  low  inclination  (<40°),  4. 
LEO  mid/high  inclination  (>40°).  Orbit  should  expose  payload  to  sufficient  radiation  to 
cause  SEEIs,  and  should  provide  a  variety  of  flux. 

2.4.1.  Standard  orbit  parameters 

□  Altitude  at  Apogee,  (km) 

As  detailed  in  section  2.4,  no  requirement. 

□  Altitude  at  Perigee,  (km) 

As  detailed  in  section  2.4,  no  requirement. 

□  Inclination,  (degrees) 

As  detailed  in  section  2.4,  no  requirement. 

2.4.2.  Launch  Window 

No  Constraints. 

2.4.3.  Desired  Mission  Life 

At  least  1  year  of  operation. 

2.5.  Success  Criteria 

The  following  would  be  considered  minimum  success  of  the  CFTP  experiment. 

□  Successful  delivery  and  launch  of  a  low-cost  experiment  by  NPS  students 
using  COTS  products 

□  One  year  of  CFTP  operation  while  exposed  to  radiation  fluxes 

□  Successful  reconfiguration  of  CFTP  after  launch 

□  Detection  and  correction  of  bit  errors  in  an  SEU  environment 

The  following  would  be  considered  acceptable  success  of  the  CFTP  experiment. 

□  Demonstrate  reconfiguration  as  a  resource  to  process  data  from  other 
experiments  or  host  systems. 

Complete  success  would  be  defined  as  completion  of  the  minimum  success  criteria  (with 
adequate  data  collected  to  evaluate  the  TMR  design)  and  continuation  of  the  acceptable 
success  criteria  by  uploading  and  reconfiguring  for  additional  missions. 

3.  PHYSICAL  DESCRIPTION 

3.1.  Engineering  Layout 

The  CFTP  payload  consists  of  a  Printed  Circuit  Board  (PCB)  with  an  FPGA  and  multiple 
Integrated  Circuits  (ICs)  for  RAM,  ROM,  and  other  supporting  logic.  Figures  3-la  and 
3- lb  provide  two-dimensional  views  of  the  board  concept  along  with  dimensions, 
coordinate  system,  connector  locations  and  bolt  pattem/bolt  size  information.  The  board 
has  a  volume  of  999  cm  and  mounts  to  the  spacecraft  using  14  #4-40  mounting  bolts. 
The  board  can  be  located  anywhere  in  the  spacecraft  that  allows  it  to  receive  exposure  to 
radiation  with  minimum  shielding. 
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Figure  3- la:  CFTP  Board  Layout  (conceptual) 


Figure  3- lb:  CFTP  Board  Layout  (engineering) 
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3.1.1.  Coordinate  System 

A  notional  coordinate  system  is  shown  in  Figure  3-lb. 

3.1.2.  Dimensions 

CFTP  board  dimensions  are  nominally  13.5cm  x  18.5cm  x  4cm  (see  Figure  3-lb). 

3.1.3.  Mechanical  Interfaces 

In  the  current  design,  the  CFTP  board  will  utilize  14  #4-40  bolts  to  mount  to  the 
spacecraft.  The  spacecraft  contractor  shall  provide  a  bolt  pattern  to  match  the 
CFTP  board  pattern  and  the  mounting  bolts  required  to  tie  down  the  box  to  the 
spacecraft-mounting  plane. 

As  a  single  board  the  CFTP  will  fasten  into  a  card  cage  or  box,  and  the  mounting 
system  can  be  modified  to  match  the  host. 

3.2.  Electrical  Connections 

Electrical  connections  required  by  the  CFTP  board  include: 

□  PC104Bus  connections : 

•  Ground 

•  Power:  ±  28VDC 

□  Possible  I/O  interfaces  with  the  spacecraft’s  Command  and  Data  Handler(s) 

•  8,  16,  or  32  bit  parallel  interface 

•  synchronous  serial  interface  at  1Mbps 

•  asynchronous  serial  interface  at  115kbps 

o  RS422 

o  Standard  9-Pin  “D”-type  connector(s) 

3.3.  Mass  properties 

3.3.1.  Weight  Summary 

The  overall  weight  of  the  CFTP  board  is  currently  estimated  at  1.0  kg. 

3.3.2.  Center  of  Mass 

Center-of-Mass  (COM)  estimates  for  the  CFTP  board  are  TBD. 

3.3.3.  Mass  Moment  of  Inertia 

Mass-Moment-of-Inertia  (MOI)  estimates  for  the  CFTP  board  are  TBD. 

3.4.  Moving  parts 

The  will  be  no  moving  parts  on  the  CFTP. 

3.5.  Mounting  and  alignment 

As  the  concept  of  this  experiment  is  to  expose  the  CFTP  board  to  radiation,  any 
structures  on  the  spacecraft  surrounding  the  plane  of  the  CFTP  should  provide  minimal 
shielding  from  radiation. 
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There  are  no  requirements  or  limitations  as  to  the  CFTP  board’s  alignment  to  the 
spacecraft  axes.  Refer  to  Figure  3- lb  for  mounting  measurements. 

3.6.  Field  of  View  (FOV)  Requirements 

There  are  no  FOV  requirements  for  the  CFTP  board. 

3.7.  Experiment  Models  /  Simulators 

At  this  time  there  are  no  mass  models  or  simulators  planned  for  delivery  to  the  spacecraft 
contractor.  A  Flight  Qualification  Unit  (FQU)  is  planned  for  use  in  the  development  of 
the  flight  board  and  for  algorithm  development  and  test  after  launch  of  the  flight  board. 

It  may  be  possible  to  use  the  FQU  for  electrical  and  mechanical  interface  testing  prior  to 
delivery  of  the  flight  unit.  Use  of  the  FQU  unit  for  this  purpose  would  be  for  limited  time 
periods  and  would  require  schedule  negotiation. 

4.  ELECTRICAL  INTERFACE  REQUIREMENTS 

4.1.  Electrical  Power  Requirements 

4.1.1.  Power  Supply 

The  CFTP  power  interface  to  spacecraft  is  on  the  CFTP  board.  The  CFTP 
requires  ±  28VDC. 

4.1.2.  Power  Consumption 

CFTP  has  a  highly  variable  power  consumption  depending  on  experiment  tasking. 
Stand  by  power  is  currently  estimated  at  0.5  watts. 

Experiment  Nominal  Power  Peak  Power  Avg  Power  Stand-By 
Unit  (W)  (W)  (W)  (W) 

CFTP  5  (est.)  11  (est.)  6  (est.)  0.5  (est.) 

Table  4. 1 .2- 1  Experiment  Power  Requirements  (estimated) 

4.2.  Input/Output  Signal  Interfaces 

4.2.1.  Bi-Directional  Interfaces  (Command/Telemetry  via  spacecraft  data 
bus) 

Possible  I/O  interfaces  with  the  spacecraft’s  Command  and  Data  Handler(s): 

□  8,  16,  or  32  bit  parallel  interface 

□  synchronous  serial  interface  at  1Mbps 

□  asynchronous  serial  interface  at  115kbps 

4.2.2.  Experiment  Inputs  (Discrete  and  Analog) 

Possible  input  interfaces  with  the  spacecraft: 

□  8,  16,  or  32  bit  parallel  interface 

□  synchronous  serial  interface  at  1Mbps 

□  asynchronous  serial  interface  at  115kbps 
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4.2.3.  Experiment  Outputs  (Discrete  and  Analog) 

Possible  output  interfaces  with  the  spacecraft: 

□  8,  16,  or  32  bit  parallel  interface 

□  synchronous  serial  interface  at  1Mbps 

□  asynchronous  serial  interface  at  115kbps 

5.  COMMAND  AND  CONTROL 

5.1.  Command  Interface 

Possible  I/O  interfaces  with  the  spacecraft’s  Command  and  Data  Handler(s): 

□  8,  16,  or  32  bit  parallel  interface 

□  synchronous  serial  interface  at  1Mbps 

□  asynchronous  serial  interface  at  115kbps 

•  RS422 

•  Standard  9-Pin  “D”-type  connector(s) 

5.2.  Spacecraft  Command  and  Data  Handling 

The  following  is  a  list  of  CFTP  requirements: 

□  Provide  a  periodic  watchdog  timer  command  to  the  experiment  in  order  to 
provide  a  maskable  capability  for  asserting  experiment  reset. 

□  The  spacecraft  shall  accept  up  to  several  Mega-bytes  (TBD)  which  could 
be  loaded  on  multiple  passes,  for  transfer  to  the  experiment. 

□  The  spacecraft  shall  provide  for  the  downlink  of  approximately  1M  bit  per 
pass  from  the  experiment. 

□  The  spacecraft  shall  be  capable  of  commanding  the  experiment  into 
standby  mode. 

5.3.  Clock/Time  reference  requirements 

Time  stamps  on  status  reports  are  desired,  with  minimum  accuracy  to  the  second. 

6.  TELEMETRY  AND  DATA  HANDLING 

6.1.  Telemetry  System 

All  telemetry  items  will  be  generated  as  status  reports  over  either  a  serial  or  parallel 
interface. 

6.2.  Experiment  Data  Collection  &  Storage 

CFTP  requests  that  the  spacecraft  supply  a  minimum  of  500k  bytes  of  memory  to  act  as  a 
“store  and  forward”  buffer. 

6.3.  Experiment  Data  Transfer 

6.3.1.  Experiment  Data  Download  Requirements 

1Mbit  per  pass. 
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6.3.2.  Data  Transfer 


Configuration  and  software  uploads  and  status  report  downloads  will  be 
transferred  at  either  the  parallel  data  transfer  rate,  1Mbps  for  synchronous  serial, 
or  115kbps  for  asynchronous  serial. 

6.3.3.  Data  Integrity 

Acceptable  bit  error  rate  (BER)  for  uplink:  2'5  BER 
Acceptable  bit  error  rate  for  downlink:  2'5  BER 

Acceptable  error  rate  for  store  and  forward  buffer:  Not  to  exceed  1  error/day. 

6.4.  Spacecraft  Data 

Spacecraft  real  time  required  on-orbit  for  error  location  determination.  Orbital  elements 
are  required  for  post-processing  on  the  ground. 

7.  ENVIRONMENTAL  REQUIREMENTS 

7.1.  Static  Load  Constraints 

The  CFTP  board  is  not  designed  to  support  mounting  of  other  experiments. 

7.2.  Vibration  Constraints 

The  CFTP  board  will  be  designed  to  meet  the  launch  environment  of  the  launch  vehicle. 

7.3.  Shock  Constraints 

The  CFTP  board  will  be  designed  to  meet  the  launch  environment  of  the  launch  vehicle. 

7.4.  Radiation  Constraints 

There  are  no  radiation  constraints,  but  desire  a  minimum  shielding  environment, 
especially  on  LEO  missions. 

The  CFTP  board  is  designed  to  operate  within  a  Total  Dose  Environment  of  10  kRads  per 
year. 

7.5.  Electromagnetic  Compatibility 

7.5.1.  Radiated  Emissions  from  Experiment 

The  CFTP  board  will  be  designed  to  meet  typical  MIL-STD46 1/462  requirements 
as  modified  by  the  spacecraft  and  launch  vehicle  contractors. 

7.5.2.  Conducted  Emissions  from  Experiment 

The  CFTP  board  will  be  designed  to  meet  typical  MIL-STD46 1/462  requirements 
as  modified  by  the  spacecraft  and  launch  vehicle  contractors. 

7.5.3.  Magnetic  Fields  Generated  by  Experiment 

There  are  currently  no  magnetic  fields  requirements  imposed  on  the  CFTP  board. 

7.5.4.  Sensitivity  of  Experiment  to  Radiated  Emissions 

The  CFTP  board  will  be  designed  to  meet  typical  MIL-STD46 1/462  requirements 
as  modified  by  the  spacecraft  and  launch  vehicle  contractors. 
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7.5.5.  Sensitivity  of  Experiment  to  Conducted  Emissions 

The  CFTP  board  will  be  designed  to  meet  typical  MIL-STD46 1/462  requirements 
as  modified  by  the  spacecraft  and  launch  vehicle  contractors. 

7.5.6.  Sensitivity  of  Experiment  to  Magnetic  Fields 

The  CFTP  board  will  be  designed  to  meet  typical  MIL-STD46 1/462  requirements 
as  modified  by  the  spacecraft  and  launch  vehicle  contractors. 

7.6.  Atmospheric  Pressure  Constraints 

No  requirements. 

7.7.  Cleanliness  Constraints 

Class  100,000. 

7.8.  Humidity  Constraints 

No  condensation  or  electrostatic  discharge. 

7.9.  Thermal  Interface  Requirements 

7.9.1.  Thermal  Isolation  (watts) 

No  requirement. 

7.9.2.  Incident  Thermal  Flux  (watts/ft2  ) 

No  requirement. 

8.  INTEGRATION  AND  TEST 

8.1.  Spacecraft  Integration  and  Test 

8.1.1.  Pre-spacecraft-integration  Inspection  &  Test 

Upon  arrival  at  the  spacecraft  contractor’s  facility,  the  CFTP  board  will  be 
visually  inspected  for  any  shipping  damage.  It  will  then  be  functionally  tested  - 
the  experiment  will  be  delivered  configured  with  a  self-test  which  will  be 
executed  upon  command  from  the  spacecraft. 

8.1.2.  Post-Spacecraft-Integration  Test  Requirements 

Functional  testing  of  the  CFTP  board  will  be  done  -  the  experiment  will  be 
delivered  configured  with  a  self-test  which  will  be  executed  upon  command  from 
the  spacecraft.  This  test  will  be  run  before  and  after  all  spacecraft  level 
environmental  tests. 

8.1.3.  Ground  Support  Equipment  (GSE)  and  Facilities 

The  CFTP  project  team  will  supply  remote  GSE  to  support  the  CFTP  experiment 
during  spacecraft  level  testing.  The  ability  to  upload  configurations,  receive 
status  data  and  download  data  remotely  is  desired.  Facilities  required  are 
telecommunications  and  internet  access  to  Ground  Control  Station. 
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8.1.4.  Ground  Handling  Procedures 

Standard  Electro-Static  Discharge  (ESD)  precautions  shall  be  enforced  during  any 
handling  of  the  CFTP  board. 

8.2.  Launch  Vehicle  (LV)  Integration  and  Test 

8.2.1.  LV  Integration  Site  Tests 

Functional  testing  of  the  CFTP  board  shall  be  performed  prior  to  and  after 
integration  of  the  spacecraft  to  the  launch  vehicle. 

8.2.2.  LV  Integration  Site  GSE  and  Facilities 

The  CFTP  project  team  will  supply  no  GSE  to  support  the  CFTP  experiment 
during  LV  level  testing. 

8.2.3.  Launch  Pad  Tests 

It  is  desired  to  perform  functional  testing  of  the  CFTP  payload  to  ensure  proper 
operation  of  the  CFTP  board  once  on  the  launch  pad. 

8.2.4.  Launch  Pad  Environment 

No  special  environmental  conditions  are  required  for  the  CFTP. 

8.2.5.  Experiment  Access 

No  access  is  required. 

8.2.6.  Launch  Go/No-Go  Criteria 

Not  applicable. 

8.3.  Potentially  Hazardous  Materials  &  Equipment 

8.3.1.  Pressurized  Systems  (Liquid/Gas) 

Not  applicable. 

8.3.2.  Ordnance  Systems 

Not  applicable. 

8.3.3.  Radiation  Sources 

Not  applicable. 

8.3.4.  High  Voltage  Source  Locations 

Not  applicable. 

8.3.5.  Experiment  Safety  During  Integration  and  Test 
TBD. 

9.  ON-ORBIT  OPERATIONS  REQUIREMENTS 

9.1.  Launch  Phase  Requirements 

There  are  no  requirements  for  operation  of  the  CFTP  board  during  launch  phase. 
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9.2.  On-Orbit  Operations 

9.2.1.  Initialization 

Automatic  power-on/initialization  sequence  will  occur. 

9.2.2.  Check-Out 

Power-on  self  test  will  report  status  of  experiment  via  PC- 104  interchange. 

9.2.3.  Experiment  Ops 

Refer  to  section  2.3,  Phases  2,  3  and  4. 

9.3.  Experiment  Turn-On 

Upon  application  of  power,  the  experiment  will  execute  a  power-on/initialization 
sequence. 

9.4.  Operations  Support 

9.4.1.  Pre-Flight  Training  and  Simulation 

Prior  to  launch,  the  CFTP  project  team  will  provide  support  for  spacecraft 
Integrated  Systems  Tests  (ISTs)  and  Mission  Simulation  Tests  (MSTs)  through 
breadboard  and  brassboard  versions  of  the  CFTP  which  will  be  available  for 
remote  access. 

9.4.2.  Data  Return,  Processing,  and  Distribution 

Provide  remote  access  to  the  data  stream  from  the  satellite  and  the  ability  to 
upload  configuration  files. 

9.4.3.  Meteorological  Services 

At  this  time  there  is  no  requirement  for  meteorological  services. 

10.  ON-ORBIT  ORIENTATION  AND  STABILIZATION 

10.1.  Attitude  Control 

At  this  time  there  is  no  requirement  for  attitude  control. 

10.2.  Attitude  Knowledge 

At  this  time  there  is  no  requirement  for  attitude  knowledge. 
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11. 


EPHEMERIS  DATA 


11.1.  Prediction/Real  Time  Knowledge 

CFTP  requires  real  time  satellite  clock,  but  no  on-orbit  ephemeris  data. 

11.2.  Post  Processed  Knowledge 

The  CFTP  experiment  requires  ephemeris  data  for  ground  processing  after  receipt  of 
experimental  data  to  determine  radiation  flux  during  post-processing. 

12.  SCHEDULE 

Experiment  design  and  delivery  dates  are  given  for  information  only  and  are  not  contractually 
binding  dates. 


The  current  CFTP  development  schedule  is  shown  in  Figure  12-1  below. 
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Figure  12-1:  CFTP  Schedule 
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13.  SECURITY 

No  security  concerns  or  safeguarding  requirements.  The  experiment  can  be  manifested  on  a 
foreign  spacecraft. 


LIST  OF  ACRONYMS 

BER 

Bit  Error  Rate 

CDR 

Critical  Design  Review 

CFTP 

Configurable  Fault  Tolerant  Processor 

COTS 

Commercial  Off-The-Shelf 

ESD 

Electro-Static  Discharge 

FPGA 

Field  Programmable  Gate  Arrays 

FQU 

Flight  Qualification  Unit 

GTO 

Geostationary  Transfer  Orbit 

I/O 

Input/Output 

IC 

Integrated  Circuits 

1ST 

Integrated  Systems  Tests 

LEO 

Low  Earth  Orbit 

MEO 

Medium  Earth  Orbit 

MST 

Mission  Simulation  Tests 

NPS 

Naval  Postgraduate  School 

PBC 

Printed  Circuit  Board 

PDR 

Preliminary  Design  Review 

SEU 

Single  Event  Upsets 

TBD 

To  Be  Determined 

TMR 

Triple  Modular  Redundancy 

REFERENCES  (if  any) 
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1.  INTRODUCTION 


1 .1 .  Scope 

This  Mission  Requirements  Document  (MRD)  is  the  aggregate  description  and 
requirements  document  for  the  Configurable  Fault  Tolerant  Processor  (CFTP)  experiment 
and  the  Internet  Communications  Satellite  (ICSat)  experiment.  ICSat  and  CFTP  are  both 
DoD  (Department  of  Defense)  Space  Experiment  Review  Board  (SERB)-ranked  payloads 
manifested  for  flight  on  the  MidSTAR-1  spacecraft. 

1 .2.  Purpose 

The  purpose  of  this  document  is  threefold: 

1.  It  confirms  the  technical  requirements  originally  established  in  the  Experiment 
Requirements  Documents  submitted  by  the  payloads,  along  with  arbitrated  or  imposed 
modifications  needed  to  accommodate  the  MidSTAR-1  mission. 

2.  It  imposes  additional  managerial,  systems  engineering,  or  additional  technical 
requirements  intended  to  amplify  or  supplement  the  Memoranda  of  Agreement  that  exist 
between  the  Space  Test  Program  and  the  experiment  agencies. 

3.  It  acts  as  a  reference  document  for  the  MidSTAR-1  team,  placing  the 
experiment  requirements  in  context  with  descriptions  of  the  experiment  hardware, 
software,  mission  and  operations  concepts. 

1.3.  Terminology,  Conventions  and  Nomenclature 

In  general,  this  document  will  use  terminology  that  conforms  to  the  definitions  given  in 
Section  3  of  MIL-STD-1540D.  In  addition,  Space  Test  Program  uses  the  following 
nomenclature: 

Experiment:  In  the  context  of  this  mission,  experiment  is  equivalent  to  space  experiment. 

Payload:  The  component(s)  of  a  space  experiment  hosted  on  a  space  vehicle. 

Experimenter(s):  The  personnel  associated  with  the  management,  design,  build,  analysis, 
test,  operation,  data  processing  and  data  interpretation  for  a  space  experiment.  Unless 
specified,  the  term  “experimenter”  may  refer  to  government  or  contractor  representatives. 

Principal  Investigator  (PI):  The  experimenter  responsible  for  setting  the  scope  of  an 
experiment  and  executing  the  experiment  program. 

Spacecraft:  The  space  vehicle  without  the  payloads  integrated.  Also  referred  to  as  the 
bus. 
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1.4.  Applicable  Documents 

1.4.1.  Compliance  Documents 

(No  Document  No.)  Secondary  Payload  Planner’s  Guide  for  Use  on  the  EELY 
Secondary  Payload  Adapter,  Version  1.0 
MDC  00H0043  Delta  IV  Payload  Planners  Guide 

EWR  127-1  Range  Safety  Requirements 


1.4.2.  Reference  Documents 


MIL-STD  1540D 

MIL-HDBK-340A 

(USAF) 

DOD-HDBK-343 

(USAF) 

MIL-STD- 1809 


Product  Verification  Requirements  for  Launch,  Upper- 
stage,  and  Space  Vehicles 
Application  Guidelines  for  MIL-STD1540;  Test 
Requirements  for  Launch,  Upper-stage,  and  Space 
Vehicles 

Design,  Construction,  and  Testing  Requirements  for  One 
of  a  Kind  Space  Equipment, 

Space  Environment  for  USAF  Space  Vehicles 


MIL-STD-461E 

MIL-STD-462D 

FED-STD-209E 

ASTM-E-595 


Requirements  For  The  Control  Of  Electromagnetic 
Interference  Characteristics  of  Subsystems  And 
Equipment 

Measurement  of  Electromagnetic  Interference 
Characteristics 

Airborne  Particulate  Cleanliness  Classes  In  Cleanrooms 
and  Clean  Zones 

Total  Mass  Loss  and  Collected  Volatile  Condensable 
Material  From  Outgassing  in  A  Vacuum  Environment 


8  Jun  2001 
Apr  2002 
31  Oct  1999 

15  Jan  1999 
1  Apr  1999 

I  Feb  1986 

15  Feb  1991 

20  Aug 
1999 

II  Jan  1993 
11  Sep  1992 
1999 
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2.  PAYLOAD  OVERVIEW 

2.1.  Payload  Description 

2.1.1.  Configurable  Fault  Tolerant  Processor  (CFTP) 

The  CFTP  payload  consists  of  three  printed  circuit  boards:  the  experiment  board,  the 
interface  board,  and  the  power  supply  board.  The  CFTP  experiment  is  a  Printed  Circuit 
Board  (PCB)  with  an  FPGA  and  multiple  Integrated  Circuits  (ICs)  for  RAM,  ROM,  and 
other  supporting  logic.  Figure  2-1  provides  a  two-dimensional  view  of  the  board  concept. 
CFTP  accepts  data  from  the  SC  processor,  processes  it  according  to  the  configuration  of 
the  FPGA,  and  returns  the  data  to  the  SC  processor.  The  interface  board  and  the  power 
supply  board  form  the  interface  with  the  spacecraft. 


Figure  2-1:  Layout  of  CFTP  Board 
2.1.2.  Internet  Communications  Satellite  (ICSat) 

ICSat  consists  of  four  components.  These  are  the  Hosted  Software,  the  Communications 
Block,  the  Amplifier  Card,  and  the  ICSat  Antenna. 

Hosted  Software:  The  Hosted  Software  is  a  Linux-based  application  that  resides  on  the 
host  vehicle  processor  (PC- 104  or  equivalent).  The  Hosted  Software  compresses  data 
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files  using  BZIP-2  protocol,  accepts  files  that  are  placed  in  an  Earth-bound  data  stream, 
formats  the  stream  into  TCP/IP,  and  provides  a  serial  output  to  the  Communications 
Block.  The  Hosted  Software  also  receives  uplinked  TCP/IP-formatted  serial  data  streams 
via  the  Communications  Block  and  converts  them  into  the  host  vehicle  format. 

Communications  Block:  The  Communications  Block  performs  modulation, 
demodulation,  transmission,  and  reception  functions.  It  accepts  a  TCP/IP  data  stream 
from  the  Hosted  Software,  modulates  the  data  stream  onto  the  downlink  frequency,  and 
outputs  the  RF  stream  to  the  amplifier.  It  also  receives  the  boosted  uplink  signal  from  the 
amplifier  and  demodulates  it,  outputting  the  TCP/IP  formatted  data  stream  to  the  Hosted 
Software 

Amplifier  Card:  The  amplifier  receives  the  uplink  RF  signal  from  the  antenna,  boosts  the 
signal,  and  forwards  it  to  the  Communications  Block. 

ICSat  Antenna:  The  antenna  is  a  quadrifilar  helix  configuration,  providing  near- 
hemispherical  coverage  around  its  boresight. 

2.2.  Operational  Concept 

All  payloads  will  be  unpowered  during  launch.  Following  the  Launch  and  Early  Orbit 
(L/EO)  phase  and  completion  of  SC  checkout,  the  payloads  will  be  powered  and  checked 
out.  Once  checkout  is  completed,  nominal  operations  will  begin. 

The  CFTP  experimenter  desires  to  operate  CFTP  continuously  for  one  year  (but  can 
support  periodic  operation,  reduced  power  or  “sleep”  modes  as  well).  The  year  of 
operation  is  broken  down  into  four  main  phases,  which  are  directly  tied  to  mission 
success. 

Phase  I:  CFTP  will  be  loaded  with  a  tested,  initial  softcore  configuration.  Once  on-orbit, 
the  experimenter  commands  CFTP,  with  this  initial  configuration  loaded,  to  execute  self¬ 
tests.  The  experimenter  examines  returned  CFTP  data  to  verify  the  operation  of  CFTP 
and  the  data  transfer  paths. 

Phase  II:  After  Phase  I,  the  experimenter  uplinks  a  reconfiguration  file  to  MidSTAR-1, 
and  executes  a  reconfiguration  sequence.  The  reconfiguration  files  will  load  the  FPGA 
with  the  TMR  softcore.  The  experimenter  evaluates  downlink  data  to  verify  that  the 
reconfiguration  executed  correctly. 

Phase  III 

With  TMR  softcore  loaded,  conduct  operations  to  detect  and  correct  for  single  event 
upsets  (SEU)  by  repeatedly  performing  benchmark  tests.  Data  outputs  to  MidSTAR-1 
consist  of  status  messages  that  report  errors  and  benchmark  results.  MidSTAR-1 
downlinks  the  status  messages  to  the  ground  station  on  a  TBD  schedule. 

Phase  IV :  Reconfigure  the  CFTP  experiment  to  evaluate  alternate  softcore  architectures. 
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ICSat  will  operate  only  during  passes  over  Annapolis  Satellite  Ground  Station  (SGS). 
ICSat  may  be  activated  on  every  pass  in  a  single  day.  MidSTAR-1  will  be  commanded 
via  its  TT&C  link  to  execute  the  ICSat  Hosted  Software.  The  Hosted  Software  will 
access  data  files  aboard  the  spacecraft,  package  them  in  TCP/IP  formats  and  submit  them 
to  the  Communications  Block.  The  ground  station  will  transmit  data  files  to  MidSTAR-1 
via  ICSat  for  later  action.  (For  example,  the  ground  station  may  transmit  command  files 
for  execution  by  the  command/control  system).  The  ground  station  will  terminate  TCP/IP 
file  transfer  prior  to  the  end  of  the  pass,  and  close  the  Hosted  Software  application. 
Standard  command  and  control  will  not  be  disabled  during  ICSat  operations. 

2.3.  Orbit  Requirements 

2.3.1.  Orbit  Parameters 

CFTP  requires  a  low  earth  orbit  above  40  degrees  inclination. 

ICSat  requires  the  orbital  perigee  and  apogee  altitudes  to  be  within  the  range  of  300  km  to 
700  km,  and  inclination  greater  than  35  degrees.  The  orbit  shall  provide  at  least  30 
minutes  in  view  of  the  SGS  per  day  above  an  elevation  angle  of  5  degrees. 

The  mission  orbit  is  currently  under  study  to  accommodate,  as  well  as  possible,  all 
payloads  manifested  on  the  MLV-05  mission.  Tentatively,  the  expected  operational  orbit 
for  MidSTAR-1  is  600  km  altitude  circular  at  46°  inclination. 

2.3.2.  Launch  Window 

There  are  no  experiment-driven  seasonal  or  time-of-day  requirements  for  the  launch. 

2.3.3.  Desired  Mission  Life 

The  desired  mission  life  for  CFTP  is  1  year. 

The  desired  mission  life  for  ICSat  is  1  year. 
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3.  PHYSICAL  DESCRIPTION 

3.1.  Engineering  Layout 

3.1.1.  CFTP 

The  CFTP  payload  consists  of  three  printed  circuit  boards:  the  experiment  board,  the 
interface  board,  and  the  power  supply  board.  These  boards  are  enclosed  in  an  aluminum 
housing.  Electrical  interface  to  MidSTAR-1  is  via  2  connectors,  one  providing  28  VDC, 
and  the  other  providing  RS-422  serial  port  data  connection  to  the  MidSTAR-1  spacecraft 
processor  The  CFTP  team  will  provide  the  housing,  all  components  internal  to  it,  and 
the  connectors  on  the  housing.  The  MidSTAR-1  team  shall  provide  the  harness  and  its 
connectors. 


3.1.2.  ICSat 

The  Communications  Block  and  Amplifier  Card  will  be  integrated  into  a  single  housing 
(referred  to  collectively  as  the  ICSat  Transceiver  Assembly,  or  IT  A)  by  the  ICSat 
experimenter.  The  location  of  boltholes  and  power  and  signal  connectors  is  to  be 
determined.  The  ICSat  team  shall  procure  all  experiment-side  connector  sets,  and  shall 
provide  the  MidSTAR-1  team  with  the  harness  portion  of  the  connector  halves.  The 
MidSTAR-1  team  will  provide  the  harness  between  the  ITA  and  the  MidSTAR-1 
Processor.  The  MidSTAR-1  team  will  also  provide  the  fastening  devices  for  securing  the 
ITA  to  the  MidSTAR-1  structure. 

The  ICSat  Antenna  is  a  quadrifilar  helix  antenna.  It  will  be  mounted  on  the  exterior  of 
the  spacecraft  IAW  requirements  given  elsewhere  in  this  document. 

3.2.  Dimensions 

CFTP  box  dimensions  are  nominally  16  cm  x  20  cm  x  8  cm  (see  Figure  3-lb). 

ICSat  Transceiver  Assembly:  Communications  block  and  amplifier  to  be  housed  in  one 
unit  not  to  exceed  25cm  x  25cm  xlO  cm. 

ICSat  Antenna:  Not  to  exceed  12cm  x  12cm  x  15cm 

3.3.  Mass  Allocations 


Table  3-1:  Mass  Allocations  for  MidSTAR-1  Payloads 


Component 

Mass,  kg 
(Current  Best 
Estimate) 

Allocated  Margin, 
kg 

Total  Mass 
Allocation,  kg 

CFTP 

Board 

1.0 

.3 

1.3 

Internal  Harness 
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ICSat 

Amplifier 

0.75 

0.25 

1.00 

Comm  Block 

4.0 

1.0 

5 

ICSat  Antenna 

0.5 

0.1 

0.6 

ITA  Chassis 

1.0 

0.5 

1.5 

Harness 

0.25 

0.1 

0.35 

3.4.  Center  of  Mass 

The  center  of  mass  for  the  CFTP  box  is  TBD. 

The  center  of  mass  for  each  ICSat  component  is  at  geometric  center  of  each  component. 
The  location  uncertainty  in  each  axis  is  of  10%  of  the  component  dimension  in  that  axis. 

3.5.  Mechanical  Interfaces  and  Integration 

The  CFTP  box  will  mount  to  the  pattern  shown  in  figure  TBS,  with  TBD  bolts 

The  ICSat  components  all  present  a  four-bolt  pattern  for  fastening.  This  includes  the 
amplifier  card,  the  communications  block,  and  the  antenna. 

3.6.  Moving  Parts  and  Deployment  Mechanisms 

Neither  CFTP  nor  ICSat  have  any  moving  parts. 

3.7.  Mounting  and  Alignment 

CFTP  has  no  requirements  for  alignment  or  orientation  with  respect  to  the  spacecraft 
axes.  CFTP  shall  be  mounted  so  that  the  shielding  from  radiation  provided  by  other  SV 
structures  and/or  components  is  minimized. 

The  ICSat  antenna  shall  be  mounted  on  a  flat  surface;  minor  deviations  in  flatness  may  be 
negotiated  with  the  ICSat  team.  The  antenna  boresight  shall  be  aligned  within  5°  of 
perpendicular  to  that  surface. 

3.8.  Field-of-View  Requirements 

The  CFTP  board  has  no  FOV  requirements. 

The  ICSat  antenna  shall  be  mounted  so  that  no  obstructions  penetrate  a  cone  of  70°  half¬ 
angle  centered  on  the  antenna  boresight,  and  obstructions  into  the  hemisphere  centered  on 
the  antenna  boresight  are  minimized 
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4.  ELECTRICAL  INTERFACE  AND  POWER  REQUIREMENTS 

4.1.  Harness  and  Connectors 

The  experimenters  shall  provide  both  halves  of  each  connector  on  the  experiment  end  of  a 
harness.  The  experimenters  shall  also  provide  at  least  one  set  of  flight  spares,  and  a  set  of 
connector  savers.  In  cases  where  this  requirement  has  an  ambiguous  application,  the 
experimenter  shall  negotiate  an  agreement  with  the  MidSTAR-1  team  and  STP. 

The  CFTP  team  shall  negotiate  connector  specifications  with  the  MidSTAR-1  team. 

The  ICSat  ITA  requires  two  separate  power  connectors,  one  each  for  the  Communications 
block  and  the  amplifier;  one  serial  port  for  command  signals;  one  serial  port  for  data 
input;  two  coax  ports,  one  for  output  to  the  transmit  antenna  and  one  for  input  from  the 
receive  antenna.  ICSat  will  provide  both  sides  of  all  non-coax  connections. 

4.2.  Power  Supply 

The  experiment  payloads  require  power  supply  lines  as  given  in  Table  4-1. 


Table  4-1:  Power  Supply  Line  Requirements  for  MidSTAR-1  Payloads 


Component 

Number  of  Power  Lines 

Notes 

5  VDC 
+  1 

VDC 

12  VDC 
+  TBD 

28 

VDC 

+8, 

-4 

VDC 

CFTP 

1 

SC  controlled  switch  on  SC 
line 

ICSat 

Amplifier 

1 

SC  controlled  switch  on  SC 
line 

Comm  Block 

1 

SC  controlled  switch  on  SC 
line 

4.3.  Payload  Power  Requirements 

4.3.1.  Power  Consumption 

The  experiments  will  draw  power  across  each  power  line  as  given  in  Table  4-2  below. 
The  power  figures  given  here  are  unmargined  current  best  estimates. 


Table  4-2:  Power  Draw  Requirements  for  MidSTAR-1  Payloads 


Component 


Power  States,  W 
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Survival 

Standby 

Operating 

Peak 

CFTP 

0.0 

0.5 

5.0 

11.0 

ICSat 

Comm  Block 

0.0 

0.0 

4 

4.0 

Amplifier 

0.0 

0.0 

10.0 

10.0 

Survival  power  is  the  power  that  must  be  provided  to  the  payload  during  nominal 
operations  when  the  payload  is  not  in  standby  or  operating.  Standby  power  is  defined  as 
the  average  power  consumption  of  an  instrument  in  a  condition  where  it  is  not  collecting 
data  but  could  start  doing  so  instantaneously  without  warm  up.  Operational  power  is 
defined  as  the  average  power  consumption  of  a  component  during  the  period  it  is 
operating.  Peak  power  is  the  maximum  instantaneous  power  that  a  component  will  draw; 
this  does  not  include  power  surges  of  less  than  1.0  milliseconds. 

4.3.2.  Power  Profiles 

Payload  power  consumption  for  typical  operations  modes  and  duty  cycles,  assuming  a  96- 
minute  orbit  duration,  are  shown  in  Table  4-3  below. 


Table  4-3:  Power  Profiles  of  MidSTAR-1  Payloads 


Experiment  Ops  Mode 

Power  Draw,  W 

Fraction  of  Orbit, 
minutes  or  %  of  orbit 

Frequency  of 
Operations 

CFTP  Processor 
Operations 

5 

100% 

Continuous 

CFTP  Configuration 
Change 

TBD 

TBD 

Once  per  week 

CFTP  Standby 

0.5 

TBD 

Only  as  needed 

ICSat  Data  Transmission 

14.0 

11  min 

Each  pass  over 
SGS 

ICSat  Standby 

4.0 

85  min 

Out  of  view  of 
SGS 

4.4.  Grounding 

The  CFTP  and  ICSat  experimenters  shall  negotiate  grounding  interfaces  with  the 
MidSTAR-1  team. 
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5.  COMMAND  AND  CONTROL,  TELEMETRY,  AND  DATA 

HANDLING 


5.1.  Bi-Directional  Interfaces 

CFTP  requires  one  RS-422  asynchronous  serial  interface  at  115kbps. 

The  ICSat  payload  requires  one  synchronous  serial  interface  with  the  SC  for 
commanding.  The  ICSat  team  will  negotiate  data  bus  specifications  and  data  transfer 
protocols  with  the  MidSTAR-1  team. 

5.2.  Spacecraft  Inputs  and  Commands 

5.2.1.  Discrete  Analog  Inputs  to  Payloads 

Neither  CFTP  nor  ICSat  use  any  discrete  analog  inputs. 

5.2.2.  Discrete  Digital  Inputs  to  Payloads 

Neither  CFTP  nor  ICSat  use  any  discrete  digital  inputs. 

5.2.3.  Spacecraft  Commanding 

CFTP  requires  the  SC  to  provide  the  following  commands: 

1.  A  periodic  watchdog  timer  command  to  the  experiment  in  order  to  provide  a 
maskable  capability  for  asserting  experiment  reset 

2.  A  command  to  place  the  experiment  into  standby  mode 

3.  A  command  to  place  the  experiment  into  active  mode 

ICSat  requires  the  SC  Flight  Software  to  execute  the  ICSat  Hosted  Software  application 
upon  command.  The  ICSat  team  shall  negotiate  the  Hosted  Software  interfaces, 
protocols,  permissions,  and  resource  management  with  the  MidSTAR-1  team. 

Futhermore,  ICSat  requires  the  SC  to  provide  for  commands  to  switch  the  power  lines  to 
ICSat  experiment  hardware.  The  ICSat  team  shall  negotiate  additional  ICSat  commands 
with  the  MidSTAR-1  team. 

5.2.4.  Software  and  Data  Uploads 

CFTP  requires  occasional  uploads  of  new  FPGA  configuration  files.  Configuration  file 
uploads  will  be  a  minimum  of  576  kbytes.  CFTP  may  also  require  uploads  of  test  data 
sets  on  the  order  of  several  Mbytes.  The  CFTP  team  shall  negotiate  the  final  data  upload 
volume  with  the  MidSTAR-1  team. 

ICSat  has  no  requirements  for  software  or  data  uploads. 

5.2.5.  Clock  or  Time  Reference  Input  Requirements 

Neither  CFTP  nor  ICSat  have  clock  or  time  reference  input  requirements. 
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5.3.  Spacecraft  Telemetry  Interface  and  Payload  Outputs 

5.3.1.  Discrete  Analog  Outputs  from  Payloads 

Neither  CFTP  nor  ICSat  use  any  discrete  analog  inputs. 

5.3.2.  Discrete  Digital  Outputs  from  Payloads 

Neither  CFTP  nor  ICSat  use  any  discrete  digital  inputs. 

5.3.3.  Payload  Data 

CFTP  requires  a  minimum  of  800  kbytes  of  SC  memory  storage  to  act  as  a  “store  and 
forward”  buffer.  The  CFTP  experimenter  shall  negotiate  additional  requirements  with  the 
MidSTAR-1  team. 

ICSat  requires  30  Mbytes  of  storage  space  for  stored  data  files  to  be  transported  over  the 
experimental  communications  link.  This  storage  requirement  does  not  include 
requirements  driven  by  the  Hosted  Software.  ICSat  requires  the  experiment  data  to  be 
maintained  until  deleted  by  ground  command.  The  ICSat  experimenter  shall  negotiate 
additional  requirements  with  the  MidSTAR-1  team. 

5.3.3. 1.  Payload  Data  Collection  and  Download  Requirements 

CFTP  requires  a  maximum  of  1  Mbit  of  data  to  be  downloaded  for  each  viable  ground 
contact. 

The  ICSat  team  shall  negotiate  a  maximum  data  volume  and  data  rate  for  downlink 
through  the  SC  communications  system  and  through  the  ICSat  communications  path. 

5.3. 3.2.  Data  Transfer 

CFTP  configuration  and  software  uploads  and  status  report  downloads  will  be  transferred 
at  the  RS-422  data  transfer  rate. 

The  ICSat  payload  requires  data  transfers  of  up  to  1  Mbit/s  to  and  from  the 
Communications  Block.  In  cases  where  the  ICSat  experiment  uses  the  spacecraft 
communications  link,  the  ICSat  experiment  shall  conform  to  spacecraft  capabilities. 

5.3.3.3.  Data  Integrity 

CFTP  data  resident  on  SC  systems  shall  not  experience  more  than  1  uncorrected  bit  error 
per  day.  CFTP  data  transmitted  (uplink  and  downlink)  over  the  MidSTAR-1  SC-to-SGS 
system  (from  data  bus  interface  with  the  payload  to  placement  on  data  distribution  server) 
shall  experience  bit-errors  at  a  rate  no  greater  than  2  in  105  averaged  over  the  total 
volume  of  data  transferred. 

ICSat  data  transmitted  (uplink  or  downlink)  over  the  MidSTAR-1  SC-to-SGS  system 
(from  data  bus  interface  with  the  payload  to  placement  on  data  distribution  server)  shall 
experience  bit-errors  at  a  rate  no  greater  than  1  in  105  averaged  over  the  total  volume  of 
data  transferred. 
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5.3.3.4.  Spacecraft  Data  Storage 

CFTP  requires  the  SC  to  time  stamp  each  status  report  it  receives  from  the  CFTP  payload. 
The  time  stamp  shall  be  accurate  to  within  1  second  of  UTC. 

5.3.3.5.  Data  Latency 

The  SC  data  identified  in  Section  5.4  shall  be  available  (on  a  data  distribution  server)  to 
the  Pis  within  3  days  of  receipt  at  the  SGS. 

5.4.  Spacecraft  Data 

The  CFTP  and  ICSat  experimenters  require  time-tagged  command  history  logs  from  the 
spacecraft.  The  experimenters  require  command  history  logs  be  available  (on  a  data 
distribution  server)  to  the  Pis  within  3  days  of  receipt  at  the  SGS. 

The  experimenters  require  that  the  SC  monitor  and  report  payload  temperatures  and 
power  supply  line  voltages  and  currents. 

This  information  shall  be  provided  to  the  Pis  in  accordance  with  the  latency 
requirements  specified  in  Section  5. 3. 3. 5  to  assist  in  payload  data  analysis.  The  SC  shall 
monitor  with  enough  resolution  to  detect  when  the  payloads  are  on. 

5.5.  ICSat  Hosted  Software 

The  ICSat  Hosted  Software  requires  a  PC- 104  or  equivalent  platform  with  Linux 
operating  system.  The  application  requires  1  Mbyte  of  storage  space. 
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6.  ENVIRONMENTAL  REQUIREMENTS 

6.1.  Static  Load  Constraints 

CFTP  and  ICS  at  hardware  components  shall  be  compatible  with  the  static  loads  provided 
by  the  MidSTAR-1  team. 

6.2.  Vibration  Constraints 

CFTP  and  ICSat  hardware  components  shall  be  compatible  with  the  vibration  loads 
provided  by  the  MidSTAR-1  team. 

6.3.  Shock  Constraints 

CFTP  and  ICSat  hardware  components  shall  be  compatible  with  the  vibration  loads 
provided  by  the  MidSTAR-1  team. 

6.4.  Atmospheric  Pressure  Constraints 

CFTP  and  ICSat  hardware  components  shall  be  compatible  with  the  depressurization 
profile  given  in  the  Delta  IV  Payload  Planner’s  Guide. 

6.5.  Radiation  Constraints 

CFTP  and  ICSat  hardware  components  shall  accept  the  radiation  environment  of  the 
mission  orbit  specified  in  2.3.1  above. 

6.6.  Electromagnetic  Compatibility 

The  payloads  shall  be  electromagnetically  compatible  with  each  other  and  with  the  SC. 

6.6.1.  Radiated  Emissions  from  the  Payloads 

The  CFTP  shall  to  meet  MIL-STD46 1/462  requirements  for  radiated  emissions,  as 
tailored  MidSTAR-1  team  and  the  IC. 

When  not  conducting  communications  experiments,  the  ICSat  payload  shall  comply  with 
MIL-STD-461  requirements  for  radiated  emissions,  as  tailored  by  the  MidSTAR-1  team 
and  the  IC.  In  addition,  during  communications  events,  ICSat  will  transmit  in  a 
frequency  band  of  2  MHz  bandwidth,  centered  on  frequency  2.4  GHz. 

6.6.2.  Conducted  Emissions  from  the  Payloads 

The  CFTP  will  be  designed  to  meet  MIL-STD46 1/462  requirements  for  conducted 
emissions,  as  tailored  MidSTAR-1  team  and  the  IC. 

The  ICSat  payload  shall  comply  with  MIL-STD-461  requirements  for  conducted 
emissions,  as  tailored  by  the  MidSTAR-1  team  and  the  IC. 

6.6.3.  Magnetic  Fields  Generated  by  the  Payloads 

The  CFTP  and  ICSat  payloads  shall  be  designed  and  built  to  generate  little  or  no 
magnetic  fields. 
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6.6.4.  Radiated  Susceptibility  of  the  Payloads 

The  CFTP  board  shall  meet  MIL-STD46 1/462  requirements  for  radiated  susceptibility,  as 
tailored  by  the  spacecraft  and  launch  vehicle  contractors.  CFTP  shall  tolerate  the  fields 
generated  by  ICSat  during  ICSat  communications  events. 

ICSat  shall  meet  MIL-STD46 1/462  requirements  for  radiated  susceptibility,  as  tailored  by 
the  spacecraft  and  launch  vehicle  contractors. 

6.6.5.  Conducted  Susceptibility  of  the  Payloads 

The  CFTP  board  and  ICSat  shall  meet  MIL-STD46 1/462  requirements  for  radiated 
susceptibility,  as  tailored  by  the  spacecraft  and  launch  vehicle  contractors. 


6.6.6.  Magnetic  Field  Susceptibility  of  the  Payloads 

The  CFTP  and  ICSat  payloads  shall  meet  MIL-STD46 1/462  requirements  for  magnetic 
field  susceptibility,  as  tailored  by  the  spacecraft  and  launch  vehicle  contractors. 

6.6.7.  Sensitivity  of  the  Payloads  to  SC  Charging 

No  requirement. 

6.7.  Cleanliness  Constraints 

The  CFTP  and  ICSat  payloads  shall  be  tolerant  of  Class  100,000  cleanliness 
environments  or  better.  The  CFTP  and  the  ICSat  payloads  shall  comply  with  the  MLV- 
05  Contamination  Control  Plan,  as  implemented  by  the  MidSTAR-1  team. 

All  CFTP  and  ICSat  payload  hardware,  and  GSE  that  will  accompany  the  hardware  in  any 
thermal  chamber,  shall  be  low-outgassing.  Low-outgassing  is  defined  as  materials  that 
have  less  than  1%  Total  Material  Loss  (TML)  and  less  than  0.10%  Collected  Volatile 
Condensable  Materials  (CVCM)  when  tested  in  accordance  with  ASTM-E-595.  If 
compliance  with  low-outgassing  criteria  cannot  be  confirmed,  the  payload  and  GSE 
hardware  shall  be  subjected  to  a  thermal  vacuum  bake,  with  exit  criteria  TBD.  STP  shall 
approve  all  exceptions  to  these  requirements. 

6.8.  Humidity  Constraints 

The  CFTP  and  ICSat  payloads  shall  be  maintained  in  a  humidity  range  in  which 
condensation  is  avoided  and  the  potential  for  inadvertent  electrostatic  discharge  is  low. 


6.9.  Thermal  Interface  Requirements 

6.9.1.  Thermal  Isolation  ( watts ) 

Neither  CFTP  nor  ICSat  have  thermal  isolation  requirements. 
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6.9.2.  Incident  Thermal  Flux  (watts/ft2  ) 

Neither  CFTP  nor  ICSat  have  incident  thermal  flux  requirements. 

6.9.3.  Temperature  Limits 

The  CFTP  and  ICSat  payload  elements  shall  be  maintained  within  the  temperature  ranges 
given  in  Table  6-1. 


Table  6-1:  Temperature  Limits  for  MidSTAR-1  Payloads 


Payload  Component 

Survival 

Temperature 

Range 

(°C) 

Operating 

Temperature 

Range 

(°C) 

Notes 

Low 

High 

Low 

High 

CFTP 

ICSat 

Amplifier 

-40 

90 

-25 

80 

Communications  Block 

-40 

90 

-25 

80 

Antenna 

-40 

90 

N/A 

N/A 
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7.  INTEGRATION  AND  TEST 

7.1.  General  Integration  and  Test  Requirements 

The  CFTP  and  ICS  at  experimenters  shall  provide  the  following  integration  and  test 
documentation: 

Payload  integration  procedures 

Payload  operating  procedures  and  constraints 

Payload  abbreviated  and  extended  functional  test  procedures,  annotated  with 
expected  payload  responses  or  response  ranges. 

Compliance  Data  Package  at  payload  delivery,  including 
ICD  compliance  verification  matrix 
Environment  test  procedures,  annotated  with  results 
Final  pre-delivery  functional  test  with  results 
Other  compliance  certifications  as  need  (e.g.,  materials  lists) 

The  experimenters  shall  inform  STP  and  the  MidSTAR-1  team  of  test  schedules  as  far  in 
advance  as  possible.  Experimenters  shall  permit  STP,  the  MidSTAR-1  team,  or 
designated  representatives  to  observe  tests  as  they  are  performed. 

Once  the  payloads  are  integrated  into  the  spacecraft,  the  experimenters  shall  support  SV 
test  efforts.  Where  needed,  the  experimenters  shall  provide  all  necessary  ground  support 
equipment  (GSE)  needed  to  properly  test,  calibrate  or  evaluate  the  payload.  For  each  test, 
the  experimenters  shall  either  provide  support  for  the  conduct  of  the  tests,  or  shall  provide 
sufficient  operating  instructions  to  permit  the  MidSTAR-1  team  to  conduct  testing 
without  the  experimenters  present.  The  experimenters  shall  review  all  payload  test 
results  for  signs  of  degradation  or  damage  within  three  days  of  each  payload  test. 

7.2.  Pre-Delivery  Payload  Integration  and  Test 

The  CFTP  and  ICSat  payloads  shall  be  subjected  to  a  tailored  protoqualification  test 
regimen  following  the  guidelines  of  MIL-HDBK-340A  and  DOD-HDBK-343  for  a  Class 
D  spacecraft  (or  equivalent  standards)  and  using  test  levels  provided  by  the  MidSTAR-1 
team  or  by  STP.  Following  the  protoqualification  tests,  the  payloads  shall  successfully 
complete  an  extensive  functional  test  prior  to  delivery  to  the  spacecraft  integration 
facility. 

7.3.  Payload-to-SC  Integration  and  Test 

7.3.1.  Post  Delivery  Inspection  &  Test 

Upon  arrival  at  the  spacecraft  integration  facility,  the  CFTP  and  ICSat  experimenters 
shall  ensure  the  payloads  survived  shipping  without  harm,  including  at  a  minimum  a 
repeat  of  the  extensive  function  test  performed  prior  to  shipment.  Each  payload  shall 
successfully  complete  the  functional  test  before  custody  of  the  payload  is  transferred  to 
the  MidSTAR-1  team. 
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7.3.2.  Post-Integration  Test 

The  experimenters  shall  support  all  payload  functional  tests  conducted  after  the  payload  is 
integrated  with  the  SC. 

7.3.3.  Ground  Support  Equipment  (GSE)  and  Facilities 

The  CFTP  and  ICS  at  experimenters  shall  supply  all  experiment  unique  GSE  during 
spacecraft  level  testing.  The  MidSTAR-1  team  will  supply  workspace,  standard  1 10V 
AC  power,  telephones,  and  Internet  access. 

7.3.4.  Ground  Handling  Procedures 

All  personnel  handling  the  payloads  shall  use  standard  electrostatic  discharge  precautions. 
All  personnel  working  near  the  ICSat  antenna  shall  observe  a  keep-out/no-hands  zone 
around  the  antenna. 

7.4.  SV  Test  Phase 

7.4.1.  Payload  Access 

The  experimenters  will  be  given  access  to  their  payloads  through  the  SC  interfaces  as 
needed.  However,  the  experimenters  shall  eschew  access  to  the  payload  hardware  that 
requires  de-integration  from  the  SV,  unless  required  to  repair  damage  or  degradation. 

7.4.2.  Environmental  Requirements 

The  experiments  will  be  maintained  within  the  environmental  constraints  established  in 
XXX.  Exceptions  will  be  identified  to  and  coordinated  with  STP  and  the  experimenters. 

7.4.3.  Ground  Support  Equipment 

The  CFTP  and  ICSat  experimenters  shall  supply  all  experiment  unique  GSE  during 
spacecraft  level  testing.  The  MidSTAR-1  team  will  supply  workspace,  standard  110V 
AC  power,  telephones,  and  Internet  access. 

7.4.4.  Integrated  Functional  Testing 

The  experimenters  shall  support  all  payload  functional  tests  conducted  during  SV 
environmental  and  functional  tests. 

7.5.  Launch  Vehicle  Integration  and  Test 

7.5.1.  LV  Integration  Site  Tests 

The  experimenters  shall  support  all  SV  functional  tests  performed  at  the  launch  site, 
including  at  a  minimum  the  post  shipment  verification  and  the  post-integration 
verification. 


7.5.2.  LV  Integration  Site  GSE  and  Facilities 

No  requirement. 
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7.5.3.  Launch  Pad  Tests 

No  requirement. 

7.5.4.  Launch  Pad  Environment 

No  requirement. 

7.5.5.  Experiment  Access 

No  requirement. 

7.5.6.  Launch  Go/No-Go  Criteria 

CFTP  will  not  have  go/no-go  criteria  beyond  its  final  functional  test  prior  to  payload 
encapsulation  in  the  LV  fairing.  ICSat  go/no-go  criteria  will  be  determined  solely  on  the 
detection  of  visible  damage  to  the  external  elements  of  ICSat. 

7.6.  Potentially  Hazardous  Materials  &  Equipment 

7.6.1.  Acoustic  Hazards 

Not  applicable. 

7.6.2.  Non-Ionizing  Radiation  Sources 

7.6.2. 1.  Radio  Frequency  Emitters 

CFTP  has  no  RF  transmitters.  The  ICSat  has  a  transmitter  that  will  radiate  through  the 
ICSat  antenna.  For  both  payloads,  unintentional  emissions  will  be  kept  within  or  shielded 
to  MIL-STD-461. 

7. 6.2. 2.  Laser  Systems 
Not  applicable. 

7.6.3.  Radioactive  (Ionizing  Radiation)  Sources 

Not  applicable. 

7.6.4.  Hazardous  Materials 

Not  applicable. 

7.6.5.  Ground  Support  Pressure  Systems  (Liquid/Gas) 

Not  applicable. 

7.6.6.  Flight  Hardware  Pressure  Systems  (Liquid/Gas) 

Not  applicable. 

7.6.7.  Ordnance  Systems 

Not  applicable. 
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7.6.8.  High  Voltage  Source  Locations 

Not  applicable. 

7.6.9.  Experiment  Safety  During  Integration  and  Test 

No  requirement. 
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8.  ON-ORBIT  PAYLOAD  OPERATIONS  REQUIREMENTS 

8.1.  Launch  Phase  Requirements 

The  payloads  shall  be  powered  off  from  liftoff  to  SV  separation  from  the  LV. 

8.2.  On-Orbit  Payload  Operations 

8.2.1.  Spacecraft  Initialization  and  Checkout 

After  SV  separation  from  the  LV  and  boot-up  of  the  SC  processor,  the  SC  will  maintain 
CFTP  and  ICSat  at  survival  temperatures  until  SC  checkout  is  complete. 

8.2.2.  Payload  Initialization  and  Checkout 

The  CFTP  payload  will  perform  a  self-test  upon  application  of  power.  CFTP  will 
generate  status  reports  via  the  RS-422  data  bus  for  downlink  to  the  SGS. 

8.2.3.  Normal  Operations 

The  CFTP  payload  will  perform  a  self-test  upon  application  of  power.  CFTP  will 
generate  status  reports  via  the  RS-422  data  bus  for  downlink  to  the  SGS. 

8.3.  Operations  Support 

8.3.1.  Pre-Flight  Training  and  Simulation 

The  experimenters  shall  support  pre-flight  training  for  the  SV  operators  as  requested  by 
the  MidSTAR-1  team. 

8.3.2.  Data  Return,  Processing,  and  Distribution 

The  experimenters  shall  retrieve  data  files  regularly  from  the  data  distribution  server, 
shall  review  it  immediately,  and  shall  request  retransmissions  within  24  hours  of  retrieval. 
The  experimenters  shall  provide  command  uploads  (or  the  equivalent  as  appropriate  to 
the  final  operations  concept)  and  data  uploads  onto  the  data  distribution  server  no  less 
than  24  hours  prior  to  the  first  need  time  for  the  data. 

8.3.3.  Meteorological  Services 

No  requirement. 
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9.  ON-ORBIT  ORIENTATION  AND  STABILIZATION 

9.1.  Attitude  Control 

CFTP  has  no  attitude  control  requirement.  ICSat  requires  the  boresight  of  the  ICSat 
antenna  to  be  pointed  within  90  degrees  of  the  SV  instantaneous  local  nadir  axis. 

9.2.  Attitude  Knowledge 

No  requirement. 
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10.  EPHEMERIS  DATA 

10.1.  Prediction/Real  Time  Knowledge 

CFTP  has  no  predictive  or  real-time  ephemeris  knowledge  requirement.  ICSat  requires 
orbit  elements  or  ephemeris  to  permit  predictions  of  SV  passes  over  the  SGS  ground 
station.  ICSat  requires  accuracy  of  the  orbital  elements  or  ephemeris  to  be  sufficient  to 
predict  pass  times  with  predicted  rise  time  accurate  to  within  ±5  minutes  of  the  actual  rise 
for  up  to  five  days  from  the  epoch  of  the  element  set  or  ephemeredes. 

10.2.  Post  Pass  Knowledge 

CFTP  requires  orbit  elements  and/or  ephemeris  to  correlate  experiment  processor  faults 
to  orbit  location.  CFTP  requires  the  accuracy  of  orbit  elements  and/or  ephemeris  to  be 
sufficient  to  locate  each  event  with  an  accuracy  of  less  than  or  equal  to  50  km.  ICSat  has 
no  requirements  for  post-pass  orbit  elements  or  ephemeris. 
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1.  Introduction 

1. 1.  Purpose 

The  purpose  of  this  MidSTAR-1  Technical  Requirements  Document  (TRD)  is  to  communicate 
the  technical  requirements  and  constraints  necessary  to  successfully  build,  test,  launch  and 
operate  the  MidSTAR-1  space  mission. 

1.2.  Scope 

MidSTAR-1  is  the  name  given  to  the  spacecraft  (SC)  that  hosts  the  Configurable  Fault  Tolerant 
Processor  (CFTP)  payload  and  the  Internet  Communications  Satellite  (ICSat)  payload.  This 
document  includes  requirements  for  the  SC  design  and  fabrication,  payload  integration,  space 
vehicle  (SV)  testing,  launch  vehicle  (LV)  integration,  launch  site  testing,  ascent  and  early  orbit 
operations  support  (SV  checkout  and  initialization),  and  mission  operations  support  for  the  space 
vehicle.  All  requirements  herein  are  mandatory  requirements. 

1.3.  Nomenclature  and  Conventions 

In  general,  this  document  will  use  terminology  that  conforms  to  the  definitions  given  in  Section  3 
of  MIL-STD-1540D.  In  addition,  Space  Test  Program  (STP)  uses  the  following  nomenclature: 

Experiment:  In  the  context  of  this  mission,  experiment  is  equivalent  to  space  experiment. 

Payload:  The  component(s)  of  a  space  experiment  hosted  on  a  space  vehicle. 

Experimenter(s):  The  personnel  associated  with  the  management,  design,  build,  analysis,  test, 
operation,  data  processing  and  data  interpretation  for  a  space  experiment.  Unless  specified,  the 
term  “experimenter”  may  refer  to  government  or  contractor  representatives. 

Principal  Investigator  (PI):  The  experimenter  responsible  for  setting  the  scope  of  an  experiment 
and  executing  the  experiment  program. 

Spacecraft  (SC):  The  space  vehicle  without  the  payloads  integrated.  Also  referred  to  as  the  bus. 

Statements  contained  within  brackets  []  are  intended  to  amplify  or  explain  requirements,  but 
need  not  be  tracked  as  requirements. 

1.4.  Applicable  Documents 


1.4.1.  Compliance  Documents 


Secondary  Payload  Planner’s  Guide  for  Use  on  the 

EELV  Secondary  Payload  Adapter,  Version  1.0 

8  Jun  2001 

Evolved  Expendable  Launch  Vehicle  Standard  Interface 
Specification,  Version  6.0 

5  Sep  2000 

MDC  00H0043 

Delta  IV  Payload  Planners  Guide 

Apr  2002 
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EWR  127-1 

Range  Safety  Requirements 

31  Oct  1999 

NSTISSP  No.  12 

National  Information  Assurance  (IA)  Policy  for  U.S. 
Space  Systems 

Jan  2001 

DoDI  3100.12 

Space  Support 

14  Sep  2000 

DoDD  4650.1 

Management  and  Use  of  the  Radio  Frequency  Spectrum 

24  Jun  1987 

DoDI  3100.12 

Space  Support 

14  Sep  2000 

1.4.2.  Reference  Documents 


MidSTAR-1  Mission  Requirements  Document 

TBD 

MIL-STD  1540D 

Product  Verification  Requirements  for  Launch,  Upper- 
stage,  and  Space  Vehicles 

15  Jan  1999 

MIL-HDBK-340A 

(USAF) 

Application  Guidelines  for  MIL-STD1540;  Test 
Requirements  for  Launch,  Upper-stage,  and  Space 
Vehicles, 

1  Apr  1999 

DOD-HDBK-343 

(USAF) 

Design,  Construction,  and  Testing  Requirements  for 

One  of  a  Kind  Space  Equipment, 

1  Feb  1986 

MIL-STD- 1809 

Space  Environment  for  USAF  Space  Vehicles 

15  Feb  1991 

FED-STD-209E 

Airborne  Particulate  Cleanliness  Classes  In  Cleanrooms 
and  Clean  Zones 

11  Sep  1992 

ASTM-E-595 

Total  Mass  Loss  and  Collected  Volatile  Condensable 
Material  From  Outgassing  in  A  Vacuum  Environment 

1999 

MIL-STD-461E 

Requirements  For  The  Control  Of  Electromagnetic 
Interference  Characteristics  of  Subsystems  And 
Equipment 

20  Aug  1999 

MIL-STD-462D 

Measurement  of  Electromagnetic  Interference 
Characteristics 

11  Jan  1993 

MIL-STD-1541E 

Electromagnetic  Compatibility  of  Space  Systems 

30  Dec  1987 

Systems  Engineering  Fundamentals  (Defense 

Acquisition  University  Press) 

Jan  2001 

1.5.  Document  Evolution 

The  requirements  in  this  document  are  high-level  requirements  that  should  remain  reasonably 
static  over  the  course  of  the  MidSTAR-1  mission.  Changes  to  these  requirements  will  be 
recorded  in  updates  to  this  TRD. 

Details  concerning  the  implementation  of  these  requirements  will  be  captured  in  other  TBD 
documents,  such  as  interface  control  drawings  and  documents,  test  plans  and  procedures,  and 
operations  checklists. 
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2.  Mission  Overview 

2. 1.  Mission  Description 

The  MidSTAR-1  mission  will  support  two  experiment  payloads  that  have  been  ranked  by  the 
Department  of  Defense  (DoD)  Space  Experiment  Review  Board  (SERB).  The  CFTP  experiment 
is  an  experiment  sponsored  and  built  by  the  Naval  Postgraduate  School  (NPS)  to  evaluate  and 
characterize  the  operation  of  a  configurable  space-borne  processor  and  a  fault-tolerant  processor 
design.  ICSat  is  a  United  States  Naval  Academy  (USNA)-sponsored  and  -built  experiment 
designed  to  demonstrate  the  use  of  internet  communications  protocol  for  satellite 
communications  up  to  1  Mbit  /sec.  Both  experiments  are  of  equal  importance  for  the  MidStar 
Mission. 

The  MidSTAR-1  SV  is  currently  planned  for  launch  on  the  STP  Launch  Mission  1  (STP-1).  The 
STP-1  mission  will  be  conducted  with  a  Delta  IV  LV  from  Cape  Canaveral  Air  Force  Base, 
Florida,  and  will  feature  the  first  use  of  the  Evolved  Expendable  Launch  Vehicle  (EELV) 
Secondary  Payload  Adapter  (ESPA).  The  primary  SV  will  be  the  Orbital  Express  satellite; 
MidSTAR-1  will  be  a  secondary.  Other  secondary  SVs  tentatively  include  Space  Test  Program 
Satellite  Mission  1  (STPSat-1,  STP);  Naval  Postgraduate  School  Satellite  1  (NPSAT1,  NPS);  and 
FalconSat-3  (Air  Force  Academy) 

Once  on  orbit,  MidSTAR-1  will  be  operated  from  the  USNA’s  Satellite  Ground  Station  (SGS)  in 
Annapolis,  MD.  USNA  personnel  will  conduct  all  mission  planning  and  execution,  and  will 
parse,  format  and  transmit  payload  data  to  the  respective  experimenters. 

2.2.  Organizations  and  Responsibilities 

2.2.1.  Space  Test  Program 

STP  exercises  overall  responsibility  and  authority  for  the  MidSTAR-1  mission,  including  the 
accommodation  of  two  SERB-ranked  experiments  and  access  to  space  via  the  STP-1  launch 
mission.  Within  STP,  two  groups  will  be  involved  directly  with  the  MidSTAR-1  mission.  The 
MidSTAR-1  System  Program  Office  (SPO)  will  monitor  the  design,  construction,  test,  and  data 
return  for  the  MidSTAR-1  SV.  The  STP-1  SPO  is  responsible  for  the  execution  of  the  entire 
STP-1  launch  mission,  and  will  set  requirements,  constraints  and  conditions  for  integrating 
MidSTAR-1  onto  the  STP-1  Integrated  Payload  Stack  (IPS). 

2.2.2.  United  States  Naval  Academy 

USNA  provides  two  mission  elements  for  the  MidSTAR-1  mission.  The  USNA  MidSTAR-1 
Team  will  design,  build  and  test  a  SC  to  accommodate  the  CFTP  and  ICSat  experiment  payloads; 
integrate  the  payloads  to  form  the  MidSTAR-1  SV;  test  and  deliver  the  SV  for  launch  on  the 
STP-1  mission;  and  operate  the  SV  on-orbit  and  distribute  experiment  data  to  the  appropriate 
organizations.  The  USNA  ICSat  Team  will  provide  the  ICSat  experiment  payload,  will  provide 
experiment  plans  and  upload  data  to  the  MidSTAR-1  Team,  and  will  evaluate  the  returned 
experiment  data. 
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2.2.3.  Naval  Postgraduate  School 

NPS  will  provide  the  CFTP  experiment  payload;  will  provide  experiment  plans  and  upload  data 
to  the  MidSTAR-1  Team,  and  will  evaluate  the  returned  experiment  data. 

2.2.4.  Evolved  Expendable  Launch  Vehicle  System  Program  Office 

The  EELV  SPO  executes  the  Delta  IV  LV  contract,  and  manages  all  LV  services. 

2.2.5.  Integrating  Contractor 

Boeing  Homeland  Security  and  Services  Company  is  the  STP-1  Integration  Contractor  (IC).  The 
IC  is  STP’s  agent  for  consolidating  all  STP-1  payload  requirements,  designing  and  implementing 
the  IPS  interfaces,  and  presenting  the  IPS  as  a  single  payload  interface  to  the  EELV  SPO. 

2.3.  Project  Interfaces 

2.3.1.  SV-to-LV  Interface 

MidSTAR-l  will  launch  as  a  secondary  payload  on  the  EELV  Boeing  Delta  IV-Medium  (with 
4m  fairing)  using  the  ESPA.  The  ESPA  is  a  cylindrical  aluminum  structure  that  duplicates  the 
EELV  Standard  Interface  Plane  (SIP)  for  the  primary  payload,  and  provides  six  15-inch  diameter 
flanges  around  its  circumference  as  stations  for  secondary  payloads.  The  exterior  surface  of  a 
secondary  flange  defines  the  Secondary  Standard  Interface  Plane  (SSIP). 

The  MidSTAR-1  SV  will  use  a  15-inch  Lightband  separation  system  provided  by  STP.  The 
Lightband  will  provide  one  15-pin  connector  for  pass  through  from  the  ESPA  harness.  In 
addition,  the  Lightband  provides  three  redundant  separation  switches  for  separation  sensing.  The 
separation  force  will  be  dictated  by  the  delta-v  requirements  established  by  STP. 

2.3.2.  SC-to-Payload  Interfaces 

The  MidSTAR-1  SC  will  interface  with  two  SERB-ranked  experiment  payloads,  CFTP  and 
ICSat.  The  interface  requirements,  as  currently  envisioned,  are  documented  in  this  TRD;  further 
context  and  amplification  may  be  found  in  the  MidSTAR-1  Mission  Requirements  Document 
(MRD).  The  MidSTAR-1  team  shall  negotiate  and  document  the  final  interface  design  details 
with  each  experiment  prior  to  the  Space  Vehicle  Critical  Design  Review. 

2.3.3.  SV-to-SGS  Interfaces 

The  MidSTAR-1  SC  will  receive  commands  and  data  uploads  from  and  send  telemetry  and 
mission  data  to  the  USNA’s  SGS.  USNA  will  manage  this  interface. 

2.3.4.  SGS-to-Experimenter  Interfaces 

The  MidSTAR-1  SGS  will  be  the  conduit  for  experimenters  to  send  commands  and  data  uploads 
to  and  receive  telemetry  and  experiment  data  from  the  experiment  payloads.  The  MidSTAR-1 
team  will  negotiate  and  document  the  final  interface  design  and  protocol  details  with  each 
experiment  prior  to  the  Space  Vehicle  Critical  Design  Review. 
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2.4.  Payload  Description 

2.4.1.  Configurable  Fault  Tolerant  Processor 

The  CFTP  payload  consists  three  printed  circuit  boards  (the  experiment  board,  the  interface 
board,  and  the  power  supply  board)  housed  in  an  aluminum  box.  The  experiment  board  is  a 
Printed  Circuit  Board  (PCB)  with  a  field  programmable  gate  array  (FPGA)  and  multiple 
Integrated  Circuits  (ICs)  for  random  access  memory  (RAM),  read-only  memory  (ROM),  and 
other  supporting  logic.  Figure  2-1  provides  a  two-dimensional  view  of  the  experiment  board 
concept.  The  interface  and  the  power  supply  board  form  the  interface  with  the  spacecraft. 
CFTP  accepts  data  from  the  SC  processor,  processes  it  according  to  the  configuration  of  the 
FPGA,  and  returns  the  data  to  the  SC  processor. 


Figure  2-1:  Layout  of  CFTP  Board 

2.4.2.  Internet  Communications  Satellite 

ICSat  consists  of  four  components.  These  are  the  Hosted  Software,  the  Communications  Block, 
the  Amplifier  Card,  and  the  ICSat  Antenna. 

Hosted  Software:  The  Hosted  Software  is  a  Linux-based  application  that  resides  on  the  host 
vehicle  processor  (PC- 104  or  equivalent).  The  Hosted  Software  compresses  data  files  using 
BZIP-2  protocol,  accepts  files  that  are  placed  in  an  Earth-bound  data  stream,  formats  the  stream 
into  Transmission  Control  Protocol/Internet  Protocol  (TCP/IP),  and  provides  a  serial  output  to 
the  Communications  Block.  The  Hosted  Software  also  receives  uplinked  TCP/IP-formatted 
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serial  data  streams  via  the  Communications  Block  and  converts  them  into  the  host  vehicle 
format. 

Communications  Block:  The  Communications  Block  performs  modulation,  demodulation, 
transmission,  and  reception  functions.  It  accepts  a  TCP/IP  data  stream  from  the  Hosted 
Software,  modulates  the  data  stream  onto  the  downlink  frequency,  and  outputs  the  RF  stream  to 
the  amplifier.  It  also  receives  the  boosted  uplink  signal  from  the  amplifier  and  demodulates  it, 
outputting  the  TCP/IP  formatted  data  stream  to  the  Hosted  Software. 

Amplifier  Card:  The  amplifier  receives  the  uplink  RF  signal  from  the  antenna,  boosts  the  signal, 
and  forwards  it  to  the  Communications  Block. 

ICSat  Antenna:  The  antenna  is  a  quadrifilar  helix  configuration,  providing  near-hemispherical 
coverage  around  its  boresight. 

2.5.  Operations  Concept 

All  payloads  will  be  unpowered  during  launch.  Following  the  Launch  and  Early  Orbit  (L/EO) 
phase  and  completion  of  SC  checkout,  the  payloads  will  be  powered  and  checked  out.  Once 
checkout  is  completed,  nominal  operations  will  begin. 

The  CFTP  experimenter  desires  to  operate  CFTP  continuously  for  one  year  (but  can  support 
periodic  operation,  reduced  power  or  “sleep”  modes  as  well).  The  year  of  operation  is  broken 
down  into  four  main  phases,  which  are  directly  tied  to  mission  success. 

Phase  I:  CFTP  will  be  loaded  with  a  tested,  initial  softcore  configuration.  Once  on-orbit,  the 
experimenter  commands  CFTP,  with  this  initial  configuration  loaded,  to  execute  self-tests.  The 
experimenter  examines  returned  CFTP  data  to  verify  the  operation  of  CFTP  and  the  data  transfer 
paths. 

Phase  II:  After  Phase  I,  the  experimenter  uplinks  a  reconfiguration  file  to  MidSTAR-1,  and 
executes  a  reconfiguration  sequence.  The  reconfiguration  files  will  load  the  FPGA  with  the 
Triple  Module  Redundancy  (TMR)  softcore.  The  experimenter  evaluates  downlink  data  to 
verify  that  the  reconfiguration  executed  correctly. 

Phase  III 

With  TMR  softcore  loaded,  conduct  operations  to  detect  and  correct  for  single  event  upsets 
(SEU)  by  repeatedly  performing  benchmark  tests.  Data  outputs  to  MidSTAR-1  consist  of  status 
messages  that  report  errors  and  benchmark  results.  MidSTAR-1  downlinks  the  status  messages 
to  the  ground  station  on  a  TBD  schedule. 

Phase  IV :  Reconfigure  the  CFTP  experiment  to  evaluate  alternate  softcore  architectures. 

ICSat  will  operate  only  during  passes  over  the  Annapolis  SGS.  ICSat  may  be  activated  on  every 
pass  in  a  single  day.  MidSTAR-1  will  be  commanded  via  its  TT&C  link  to  execute  the  ICSat 
Hosted  Software.  The  Hosted  Software  will  access  data  files  aboard  the  SC  (which  may  include 
ICSat  data  from  previous  uploads,  other  payload  data,  or  SC  telemetry),  package  them  in  TCP/IP 
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formats  and  submit  them  to  the  Communications  Block.  The  SGS  will  transmit  data  files  to 
MidSTAR-1  via  ICSat  for  later  action.  (For  example,  the  SGS  may  transmit  command  files  for 
execution  by  the  command/control  system).  The  SGS  will  terminate  TCP/IP  file  transfer  prior  to 
the  end  of  the  pass,  and  close  the  Hosted  Software  application.  Standard  command  and  control 
will  not  be  disabled  during  ICSat  operations. 


3.  Mission  Objectives  and  Success  Criteria 

3.1.  MidSTAR-1  Objectives 


No. 

Importance 

Objective 

1 

Primary 

Educate  First  Class  Midshipmen  in  the  Astronautics  curriculum 
of  the  Aerospace  Engineering  major  in  spacecraft  design,  systems 
engineering,  program  management  techniques,  cost,  scheduling, 
flight  certification,  safety  procedures,  and  spacecraft  testing. 

-  Minimum  Success:  Construction  of  MidSTAR-1  SV 
completed. 

-  Nominal  Success:  Completed  MidSTAR-1  SV  is  delivered  to 
Cape  Canaveral  launch  base  for  integration  with  STP-1. 

2 

Primary 

Integrate,  test,  launch  and  operate  a  space  vehicle  to  support  two 
SERB -rated  space  experiments  on-orbit. 

-  Minimum  Success:  SV  provides  on-orbit  support  sufficient  for 
at  least  one  experiment  to  satisfy  minimum  success  criteria. 

Should  both  payloads  terminally  malfunction  (not  induced  by  a 

SC  fault  or  misoperation)  prior  to  either  satisfying  minimum 
success,  the  mission  will  be  declared  a  minimum  success. 

-  Nominal  Success:  SV  provides  on-orbit  support  sufficient  for  at 
least  one  experiment  to  satisfy  nominal  success  criteria.  Should 
both  payloads  terminally  malfunction  (not  induced  by  a  SC  fault 
or  misoperation)  prior  to  either  satisfying  nominal  success,  but 
after  at  least  one  experiment  has  achieved  minimum  success,  the 
mission  will  be  declared  a  nominal  success. 

-  Complete  success:  SV  provides  on-orbit  support  sufficient  for 
at  least  one  experiment  to  satisfy  complete  success  criteria. 

Should  both  payloads  terminally  malfunction  (not  induced  by  a 

SC  fault  or  misoperation)  prior  to  either  satisfying  complete 
success,  but  after  at  least  one  experiment  has  achieved  nominal 
success,  the  mission  will  be  declared  a  complete  success. 

3.2.  CFTP  Objectives 


No. 

Importance 

Objective 

1 

Primary 

Provide  a  hands-on  educational  tool  for  officer  students  at  the 

NPS  in  the  design,  development,  testing,  and  on-orbit  operations 
of  processor  architecture. 

Minimum  success:  Complete  on-orbit  check-out  of  the  CFTP 
experiment  with  no  mission  terminal  anomalies. 
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Nominal  Success:  Successfully  reconfigure  the  CFTP  processor 
one  time  while  on-orbit. 

2 

Primary 

Expose  the  CFTP  experiment  to  the  radiation  fluxes  in  the 
MidSTAR-1  mission  orbit  and  contribute  data  to  characterize  the 
design  response  in  numerous  space  radiation  environments. 
Minimum  success:  Operate  intermittently  (powered  on  less  than 
85%  of  the  time)  in  the  orbital  environment  for  one  year. 

Nominal  Success:  Operate  continuously  (powered  on  greater  than 
or  equal  to  85%  of  the  time)  in  the  MidSTAR-1  orbit  for  at  least 
one  year 

3 

Secondary 

Evaluate  the  on-orbit  performance  of  a  triple-redundant,  fault- 
tolerant  computer  design  to  mitigate  bit  errors  in  computation. 
Minimum  success:  Detect  and  correct  at  least  one  bit  error 
resulting  from  an  SEU. 

4 

Secondary 

Demonstrate  commercial-off-the-shelf  (COTS)  technology  as 
applied  to  spacecraft  architecture  to  decrease  development  time 
and  costs,  and  increase  reliability  in  hardware  development  and 
implementation. 

5 

Secondary 

Contribute  data  and  experience  to  the  overall  evaluation  of 
reconfigurable  processors  as  cost-effective,  flexible  alternatives 
to  custom-designed  integrated  circuit  architectures  across  the 
spectrum  of  military  applications. 

Minimum  success:  Successfully  reconfigure  CFTP  once  after 
launch. 

Complete  success  would  be  defined  as  completion  of  the 
minimum  success  criteria  (with  adequate  data  collected  to 
evaluate  the  TMR  design)  and  continuation  of  the  acceptable 
success  criteria  by  uploading  and  reconfiguring  for  additional 
missions. 

6 

Secondary 

To  demonstrate  the  value  of  reconfigurable  processors  as  cost 
effective  flexible  alternatives  to  custom  integrated  circuit 
architectures  across  the  spectrum  of  military /DoD  applications. 
Nominal  Success:  Demonstrate  reconfiguration  as  a  resource  to 
process  data  from  other  experiments  or  host  systems. 

3.3.  ICSat  Objectives 


No. 

Importance 

Objective 

1 

Primary 

Educate  First  Class  Midshipmen  in  the  Astronautics  curriculum 
of  the  Aerospace  Engineering  major  in  spacecraft  design,  systems 
engineering,  program  management  techniques,  cost,  scheduling, 
flight  certification,  safety  procedures,  and  spacecraft  testing. 

-  Minimum  Success:  Delivery  of  flight-ready  midshipman- 
designed  and  constructed  experiment  package  to  the  SC 
integrator. 

-  Nominal  Success:  Achieve  minimum  success  for  ICSat 

Objective  2 
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2  Secondary 


Demonstrate  the  use  of  TCP/IP  communications  protocol  for 
space-to-ground  data  transmission. 

Minimum  success:  Successful  transfer  of  data  and/or  command 
files  with  TCP/IP  using  satellite’s  communication  link 
Nominal  Success:  Successful  transfer  of  data/command  files  at 
1Mbps  with  TCP/IP  using  experimental  Communications  Block 
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4.  System  Program  Office  Requirements 

4. 1.  Mission  Design  Requirements 

4.1.1.  Mission  Orbit 

The  SC  shall  be  compatible  with  the  mission  orbit  assigned  by  the  STP-1  Program  Office. 
Pending  the  results  of  feasibility  studies,  the  mission  orbit  for  MidSTAR-1  is  600  km  altitude 
circular  at  46°  inclination. 

4.1.2.  Debris  Mitigation 

The  MidSTAR-1  team  shall  ensure  the  SC  design  and  operations  minimize  the  generation  of  on- 
orbit  debris  in  accordance  with  Section  6.3  of  Department  of  Defense  Instruction  (DODI) 
3100.12. 

4.1.3.  Mission  Life  and  Reliability 

The  MidSTAR-1  team  shall  design  and  test  the  SC  to  maximize  the  probability  that  the  SV  will 
successfully  separate  from  the  launch  system.  Furthermore,  the  MidSTAR-1  team  should 
optimize  the  probability  that  the  SV  will  achieve  nominal  success. 

4.1.4.  End-of-Life 

The  MidSTAR-1  team  shall  plan  for  the  disposal  of  the  MidSTAR-1  SV  at  its  end-of-life  in 
accordance  with  Section  6.4  of  DODI  3100.12.  The  disposal  plan  for  the  SV  shall  incorporate 
debris  mitigation  measures  in  accordance  with  Section  6.3  of  DODI  3100.12.  The  MidSTAR-1 
SV  design  shall  permit  ground  personnel  to  disable  all  SV  transmitters  upon  reaching  end-of-life. 

4.2.  Project  Management 

4.2.1.  Formal  Reviews 

The  MidSTAR-1  team  shall  conduct  the  design  reviews  listed  in  the  following  subparagraphs  at 
the  appropriate  stages  of  spacecraft  development.  The  MidSTAR-1  team  and  STP  will  establish 
entrance  and  exit  criteria  prior  to  each  design  review. 

The  MidSTAR-1  team  shall  participate  in  payload  instrument  design  reviews.  The  MidSTAR-1 
team  shall  report  to  STP  any  potential  problems  posed  by  a  payload  that  may  affect  the 
performance  or  reliability  of  the  SV. 

4.2. 1.1.  Preliminary  Design  Review 

The  MidSTAR-1  team  shall  conduct  a  PDR  and  provide  an  overview  of  the  mission  concept,  SC 
design,  launch  services,  preliminary  integration  &  test  plans,  a  detailed  schedule,  instruments’ 
status,  mission  operations  concept,  and  presentation  of  draft  interface  documents.  Payload  loads 
and  environment  test  levels  shall  be  specifically  addressed  within  this  review.  Concept  must 
have  significant  depth  and  detailed  analysis  to  permit  STP  evaluation  and  understanding  of  the 
design  implementation  and  requirements  compliance.  All  mechanical  and  electrical  interfaces  to 
the  STP-1  LV  shall  be  finalized  to  the  greatest  extent  possible  by  PDR.  [According  to  Systems 
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Engineering  Fundamentals,  “~15%  of  production  drawings  are  released  by  PDR.  This  rule  is 
anecdotal  and  only  guidance  relating  to  an  “average”  defense  hardware  program.”] 

4.2.1.2.  Critical  Design  Review 

The  MidSTAR-1  team  shall  conduct  a  CDR  and  present  a  detailed  presentation  of  the  mission, 
including  final  SC  design,  mission  operations  concept,  software  review,  I&T  plans,  updated  cost 
and  schedule  performance,  updated  metrics,  and  presentation  of  final  interface  documents.  CDR 
will  include  a  presentation  of  the  payloads  status  and  schedules.  [According  to  Systems 
Engineering  Fundamentals,  “At  CDR  the  design  should  be  at  least  85%  complete.  Many 
programs  use  drawing  release  as  a  metric  for  measuring  design  completion.  This  rule  is 
anecdotal  and  only  guidance  relating  to  an  “average”  defense  hardware  program.”] 

4.2.1.3.  Payload  Integration  Readiness  Review 

The  MidSTAR-1  team  shall  conduct  a  Payload  Integration  Readiness  Review  (PIRR)  to 
demonstrate  that  the  SC  is  ready  for  payload  delivery.  The  MidSTAR-1  team  shall  present  a 
summary  of  the  fabrication,  assembly,  and  testing  of  the  SC,  provide  proof  of  compliance  to 
established  Interface  Control  Documents  (ICDs),  present  a  summary  of  major  discrepancies  and 
their  corrective  actions.  The  MidSTAR-1  team  shall  present  final,  detailed  integration  and  test 
(I&T)  procedures  and  updated  cost,  schedule,  and  program  metrics. 

4.2.1.4.  Space  Vehicle  Test  Readiness  Review 

The  MidSTAR-1  team  shall  conduct  a  Test  Readiness  Review  (TRR)  to  demonstrate  that  the  SV 
is  ready  for  environmental  testing,  compatibility,  and  final  functional  testing.  The  MidSTAR-1 
team  shall  present  resolution  of  all  prior  anomalies  and  problems;  final  functional  and 
environmental  test  procedures;  anomaly  resolution  procedures;  Government  participation 
requirements  (including  STP  and  Pis’);  and  success  criteria. 

4.2.1.5.  SV  Pre-Shipment  Review/Mission  Readiness  Review 

The  MidSTAR-1  team  shall  conduct  a  Pre-Shipment  Review  (PSR)  and  obtain  STP  approval  to 

ship  the  SV  to  the  launch  site.  The  MidSTAR-1  team  shall  support  an  STP-directed  Mission 
Readiness  Review  (MRR),  the  purpose  of  which  is  to  review  and  approve  the  SV  and  LV  system 
test  data.  At  this  meeting,  the  MidSTAR-1  team  shall  demonstrate  that  the  SV  is  ready  for 
delivery  to  the  launch  site,  personnel  are  ready  to  support  LV  I&T,  and  that  launch  site 
procedures  will  not  damage  the  SV. 

4.2.1.6.  Flight  Readiness  Review 

The  MidSTAR-1  team  shall  demonstrate  at  the  Flight  Readiness  Review  (FRR)  that  the  SV  is 
ready  for  launch.  The  MidSTAR-1  team  shall  review  anomalies,  their  resolution,  and  all 
deviations. 

4.2.1.7.  Launch  Readiness  Review 

The  MidSTAR-1  team  shall  support  the  Launch  Readiness  Review  (LRR). 
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4.3.  Systems  Engineering 

4.3.1.  Technical  Budgets  and  Margins 

The  MidSTAR-1  team  shall  develop  technical  budgets,  reserves  and/or  margins  for  all 
performance  metrics  (e.g.,  mass,  power,  pointing  control  authority  and  knowledge, 
telecommunication  link  performance).  The  MidSTAR-1  team  shall  develop  reserve  and/or 
margin  allocation  schedules  linked  to  major  milestones  or  design  progress.  The  MidSTAR-1 
team  shall  allocate  margin  to  all  unmargined  payload  requirements  and/or  properties  in 
accordance  with  margin  allocation  criteria  they  select  or  devise. 

4.3.2.  Payload  Support  Verification 

The  MidSTAR-1  SC  shall  provide  telemetry  of  SC  systems  sufficient  to  verify  that  the  SC  is 
properly  accommodating  the  experiment  requirements.  Examples  of  such  telemetry  points 
include,  but  are  not  limited  to,  voltages  and  currents  in  power  supplies  provided  to  the 
experiment  payloads,  temperatures  of  payload  reference  points,  deployment  sensors,  attitude 
measurements,  etc. 

4.3.3.  Engineering  Analyses 

The  MidSTAR-1  team  shall  provide  static  and  dynamic  structures  models,  thermal,  mass 
properties,  attitude  control  stability,  power,  electromagnetic  compatibility  (EMC), 
communications  links,  and  reliability  analyses  for  review  by  STP  and  designated  representatives, 
the  experimenters,  and  the  integration  contractor  as  appropriate. 

The  MidSTAR-1  team  shall  deliver  the  following  drawings  to  the  IC  in  accordance  with  the  IC 
Integrated  Master  Schedule: 

Contamination  Control  Requirements 
Payload  Thermal  Analysis 

[In  the  titles  of  these  documents,  “Payload”  actually  refers  to  the  SV.] 

4.3.4.  Technical  Documentation 

The  MidSTAR-1  team  shall  deliver  the  following  technical  documents  to  the  IC  in  accordance 
with  the  IC  Integrated  Master  Schedule: 

Spacecraft  Questionnaires  (Draft  and  Final) 

Spacecraft  Launch  Operations  Plan 
Spacecraft  Integration  Procedures 
Interface  Requirements  Document 
Spacecraft  Critical  Design  Review  package 
Spacecraft  Test  Documents 
Payload  Program  Requirements 
Payload  Facility  Requirements 
Mission  Operations  and  Support  Requirements 

The  MidSTAR-1  team  shall  provide  technical  input  to  the  following  documents  to  be  delivered 
by  the  IC  in  accordance  with  the  IC  Integrated  Master  Schedule: 

Interface  Control  Document 
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Missile  System  Pre-launch  Safety  Plan 
Vehicle  Information  Memorandum 

[In  the  titles  of  these  documents,  “Spacecraft”  and  “Payload”  actually  refer  to  the  SV.] 

4.3.5.  Detailed  Design  Drawings 

Drawings  shall  include  assembly  drawings,  complete  SC  electrical  schematics,  wiring  drawings 
and  lists,  mechanical  and  electrical  layouts,  materials  list,  approved  parts  list,  and  coatings.  The 
MidSTAR-1  team  shall  make  these  available  to  STP  in  a  central  repository.  Selected  items  shall 
be  delivered  to  STP  upon  request. 

The  MidSTAR-1  team  shall  deliver  the  following  drawings  to  the  IC  in  accordance  with  the  IC 
Integrated  Master  Schedule: 

Spacecraft  Computer  Aided  Design  (CAD)  models 
Spacecraft  Mass  Properties 
Spacecraft  Drawings 
Spacecraft  Dynamic  Models 

[In  the  titles  of  these  documents,  “Spacecraft”  and  “Payload”  actually  refer  to  the  SV.] 

4.4.  Testing  Requirements 

4.4.1.  General  Test  Program  Requirements 

The  MidSTAR-1  team  shall  plan  and  execute  the  verification  effort.  The  verification  program 
shall  use  the  appropriate  inspection,  demonstration,  test,  and  analysis  techniques  to  verify  all 
requirements. 

The  MidSTAR-1  team  shall  plan  and  execute  a  tailored  test  program,  with  STP  concurrence,  as 
part  of  an  overall  verification  of  the  SV  and  ground  system  compliance  to  mission  requirements. 
Testing  and  tailoring  should  be  accomplished  in  accordance  with  the  guidance  in 
MIL-HDBK-340A  and  DOD-HDBK-343  for  a  Class  D  SC  (or  equivalent  standards)  except  as 
specified  otherwise.  The  requirements  in  this  TRD  assume  a  proto-qualification  test  strategy  for 
a  single  flight  unit;  the  MidSTAR-1  team  may  propose  an  alternate  test  strategy  with 
justification. 

Levels  chosen  for  environmental  tests  shall  include  or  envelop  all  possible  anticipated  shipping, 
handling,  integration,  launch,  and  flight  conditions.  STP  will  provide  information  on  the  launch 
environment  to  the  MidSTAR-1  team. 

The  MidSTAR-1  team  shall  derive  the  appropriate  component  environmental  test  levels  and 
provide  these  to  the  experiment  Pis  and  to  STP.  The  MidSTAR-1  team  shall  also  provide 
measured  or  calculated  loads  (static,  vibration  and/or  shock)  at  the  payload  mounting  locations. 
The  MidSTAR-1  team  shall  validate  any  models  used  to  calculate  loads. 

All  SC-level  testing  and  beyond  shall  be  conducted  using  configuration-controlled  versions  of 
flight  software.  Deficiencies  found  in  ground  testing  shall  be  corrected  before  the  last  end-to- 
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end  test.  Deficiencies  found  during  initialization  and  checkout  should  be  corrected  before  first 
year  operations  begin. 

The  MidSTAR-1  team  shall  allow  STP  personnel,  the  experiment  Pis,  or  their  designated 
representatives  to  observe  testing. 

4.4.2.  Test  Planning 

The  MidSTAR-1  team  shall  produce  and  submit  a  System  Integration  and  Test  Plan.  The 
System  Integration  and  Test  Plan  shall  include  an  overview  of  the  test  program,  plus  test  specific 
plans.  The  overview  should  show  the  integration  and  test  flow,  including  the  integration  points 
for  major  items  (payloads,  mass  models,  Lightband,  SC  components,  etc.),  configuration 
changes,  transportation,  and  other  logistical  considerations.  It  should  also  address  retesting  for 
failures  that  result  from  part  malfunctions  or  inadequate  design. 

Each  test-specific  plan  shall  include  the  objectives  for  each  test  referenced  to  primary  and/or 
derived  requirements,  a  description  of  test  facility  for  each  test,  the  configuration  of  the  space 
vehicle,  test  entrance  criteria,  test  exit  criteria,  test  success  criteria,  and  a  detailed  description  of 
for  all  I&T  activities.  The  System  Integration  and  Test  Plan  shall  include  unit-level 
environmental  testing;  spacecraft  level  functional  tests;  experiment  payload  environmental 
testing;  hardware  bake-outs;  experiment  payload  pre-  and  post-shipment  functional  tests; 
experiment  payload  integration;  space  vehicle  environmental,  EMC,  and  functional  tests;  system 
end-to-end  testing;  LV  integration;  and  on-orbit  test  and  check-out. 

At  least  30  days  prior  to  each  test,  the  MidSTAR-1  team  shall  provide  STP  and  the  involved 
experimenters  with  written  test  procedures  that  include  step-by-step  checklists,  acceptable 
system  response  (or  range  of  responses)  to  each  step,  a  designated  space  to  record  the  actual 
response,  and  initials  for  the  test  conductor  and  any  quality  control  personnel. 

The  MidSTAR-1  team  shall  document  the  test  configuration  for  all  environmental  tests  by 
photography  or  videography. 

4.4.3.  Spacecraft  Simulator 

The  MidSTAR-1  team  shall  provide  a  spacecraft  simulator  for  use  by  the  experimenters.  At  a 
minimum,  the  simulator  shall  permit  the  experimenters  to  verify  connectors,  pin-outs,  and 
communication  protocols.  [Other  suggested  functions  for  the  spacecraft  simulator  include 
providing  a  command  interface  for  the  experimenters,  supporting  software  and  data  uploads,  and 
demonstrating  telemetry  collection  and  file  handling.] 

4.4.4.  Payload  Integration 

Prior  to  integration  of  the  experiment  payloads  onto  the  SC,  the  experiment  payloads  and  the 
spacecraft  components  shall  have  successfully  completed  environmental  and  functional  testing. 
Furthermore,  the  MidSTAR-1  team,  the  experimenters,  and  STP  shall  verify  all  SC  and  payload 
interfaces  and  review  all  test  data  to  ensure  all  hardware  and  software  is  clear  to  be  mated. 
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4.4.5.  Space  Vehicle  Qualification  and  Acceptance 

The  MidSTAR-1  team  shall  perform  at  least  one  separation  test  using  the  flight  Lightband 
system. 

SV  thermal  vacuum  testing  shall  include  a  minimum  of  eight  (8)  cycles  with  full  functional  tests 
conducted  at  the  high  and  low  extremes  of  the  first  and  last  cycles.  The  last  three  cycles  shall  be 
anomaly  free.  Simulated  operations  representative  of  the  mission  activities  and  scenarios, 
including  typical  commanding,  tracking,  and  telemetry  contacts,  should  be  conducted  during  the 
thermal  vacuum  testing. 

4.4.6.  End-to-End  Test 

The  MidSTAR-1  team  shall  conduct  at  least  one  end-to-end  test  using  the  SV,  the  SGS  (or  a 
reasonable  facsimile),  and  communication  links  to  the  experimenter  agencies  representative  of 
the  ones  to  be  used  during  on-orbit  operations.  These  tests  shall  exercise  typical  data  flow 
including  commanding  to  payloads  and  SC  subsystems,  payload  data  collection,  spacecraft 
processing,  and  data  downlink  operations. 

The  flight  software,  ground  station  software,  command  databases  and  telemetry  databases  that 
are  used  in  the  final  end-to-end  test  shall  be  the  final  configurations  released  prior  to  launch. 

4.4.7.  24-Hour  Mission  Simulation  Test 

The  MidSTAR-1  team  shall  conduct  at  least  one  24-hour  Mission  Simulation  test  (a.k.a.  “Day- 
in-the-Life”  test).  The  Mission  Simulation  test  shall,  to  the  greatest  extent  possible,  exercise  the 
SV  systems  and  payloads  in  a  manner  similar  to  its  operations  on  orbit.  For  this  test,  the 
MidSTAR-1  team  shall  document  the  test  procedures  and  the  results  for  presentation  at  later 
readiness  reviews.  (The  purpose  of  this  test  is  to  gain  confidence  that  the  spacecraft  will  support 
the  operations  concept.  Sometimes,  certain  design  failure  modes  that  become  manifest  in  long- 
duration  operations,  such  as  memory  fragmentation,  input/output  overload,  etc.,  only  become 
apparent  at  a  system  level). 

4.5.  Mission  Support  Requirements 

4.5.1.  Security 

The  MidSTAR-1  team  shall  identify  and  conform  to  all  security  regulations  that  apply  to  their 
facilities. 

The  MidSTAR-1  Team  shall  ensure  that  foreign  nationals  assigned  to  the  MidSTAR-1  project  or 
to  the  associated  experimenters  are  not  given  access  to  data  concerning  the  Delta-IV  launch 
vehicle  or  the  activities  associated  with  the  design,  integration,  test  and  deployment  of  the  IPS. 

4.5.2.  Health  and  Safety 

The  MidSTAR-1  team  shall  identify  and  conform  to  all  health  and  safety  requirements  that  apply 
to  facilities  used  in  the  design,  construction  and  test  of  the  MidSTAR-1  SV. 
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4.5.3.  Environmental  Assessment 

The  MidSTAR-1  team  shall  support  STP’s  environmental  assessment  activities  by  providing 
data  on  materials,  failure  modes  and  probabilities,  or  other  data  as  required. 

4.5.4.  Frequency  Allocation 

The  MidSTAR-1  team  shall  obtain  frequency  allocations  for  the  SC  and  the  ICSat  experiment. 

4.5.5.  Encryption 

The  MidSTAR-1  team  shall  comply  with  the  encryption  requirements  of  National  Security 
Telecommunications  and  Information  Systems  Security  Policy  (NSTISSP)  No.  12.  [The 
MidSTAR-1  team  may  pursue  a  waiver  for  uplink  and  downlink  encryption  IAW  NSTISSP 
No.  12.  However,  if  a  waiver  is  denied,  the  MidSTAR-1  team  must  encrypt  communications 
IAW  National  Security  Agency  (NSA)  and  United  States  Navy  (USN)  guidelines.] 
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5.  Experiment  Requirements 

5. 1.  Payload  Coordinate  Systems 

No  requirement. 

5.2.  Interface  Allocations 

The  MidSTAR-1  Team  shall  provide  all  fastening  devices  for  securing  the  CFTP  payload.  The 
MidSTAR-1  team  shall  provide  the  harness  and  its  connectors.  The  CFTP  team  will  provide  the 
connectors  on  the  housing. 

The  ICSat  team  will  procure  all  experiment-side  connector  sets,  and  will  provide  the 
MidSTAR-1  team  with  the  SC  side  of  the  connector  halves.  The  MidSTAR-1  team  shall  provide 
the  harness  between  the  ICSat  assembly  and  the  MidSTAR-1  Processor.  The  MidSTAR-1  team 
shall  also  provide  the  fastening  devices  for  securing  the  ICSat  assembly  to  the  MidSTAR-1 
structure. 

5.3.  Physical  Interfaces 

5.3.1.  Physical  Properties 

5.3.1.1.  Dimensions 

The  MidSTAR-1  SC  shall  accommodate  the  payload  dimensions  as  negotiated  with  the 
experimenters  and  STP. 

[Current  dimensions  for  the  experiments  are  as  follows: 

CFTP  box  dimensions  are  16  cm  x  20  cm  x  8cm. 

ICSat  Transceiver  Assembly:  25  cm  x  25  cm  x  10  cm 
ICSat  Antenna:  Not  to  exceed  12cm  x  12cm  x  15cm] 


5.3.1.2.  Mass  Properties 

The  MidSTAR-1  SC  shall  accommodate  the  payload  mass  properties  as  negotiated  with  the 
experimenters. 

[Current  estimate  of  the  total  mass  is  TBD  kg  for  the  CFTP  payload,  and  8.45  kg  for  ICSat. 
Centers  of  gravity  for  each  payload  component  are  currently  estimated  to  be  the  geometric 
centers  of  gravity.] 

5.3.1.3.  Surface  Properties 

No  requirement. 
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5.3.2.  Mechanical  Interfaces 

5.3.2.I.  Fastening  and  Contact 

[The  CFTP  board  will  bolts  to  mount  to  the  SC;  type  and  mounting  pattern  TBS.  The  ICSat 
components  all  present  a  four-bolt  pattern  for  fastening.  This  includes  the  amplifier  card,  the 
communications  block,  and  the  antenna.] 

53.2.2.  Alignment  and  Orientation 

The  MidSTAR-1  SC  shall  mount  the  CFTP  payload  so  that  the  radiation  shielding  provided  by 
other  SV  structures  and/or  components  is  minimized.  [CFTP  has  no  requirements  for  alignment 
or  orientation  with  respect  to  the  SC  axes.] 

The  MidSTAR-1  SC  shall  mount  the  ICSat  Antenna  on  a  flat  surface.  [The  MidSTAR-1  team 
may  negotiate  minor  protrusions  or  deviations  in  flatness  of  the  antenna  surface  with  the  ICSat 
experimenter.]  The  MidSTAR-1  team  shall  align  the  antenna  boresight  within  5°  of 
perpendicular  to  the  antenna-mounting  surface. 

5.3.23.  Fields-of-View 

The  CFTP  board  has  no  field-of-view  (FOV)  requirements. 

The  MidSTAR-1  SC  shall  mount  the  ICSat  Antenna  so  that  no  obstructions  penetrate  a  cone  of 
70°  half-angle  centered  on  the  antenna  boresight,  and  obstructions  into  the  hemisphere  centered 
on  the  antenna  boresight  are  minimized. 

5.3.2.4.  Load  Paths 

The  MidSTAR-1  team  shall  not  mount  SV  hardware  to  any  payload  hardware  in  a  manner  that 
transmits  loads  through  the  payload  hardware. 

5.3.3.  Moving  Parts  and  Deployable  Mechanisms 

No  requirement.  [Neither  CFTP  nor  ICSat  have  any  moving  parts  or  deployable  mechanisms.] 

5.3.4.  Electrical  Connectors  and  Harnesses 

The  MidSTAR-1  team  shall  negotiate  the  specifications  for  connectors  and  harnesses  with  the 
experimenters. 

[Each  experimenter  will  provide  both  halves  of  each  connector  on  the  experiment  end  of  a 
harness.  Each  experimenter  will  also  provide  at  least  one  set  of  flight  spares,  and  a  set  of 
connector  savers. 

The  ICSat  ITA  requires: 

Power  connector  for  the  communications  block 

Power  connector  for  the  amplifier 

One  serial  port  for  command  signals 

One  serial  port  for  data  input 

One  coax  port  for  output  to  the  transmit  antenna 
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One  coax  port  for  input  from  the  receive  antenna 

] 

5.4.  Electrical  Power 

5.4.1.  Voltage  and  Current 

The  MidSTAR-1  SC  shall  provide  one  switched  28  YDC  +8/-4  VDC  power  line  to  the  CFTP 
payload. 

The  MidSTAR-1  SC  shall  provide  one  switched  12  YDC  ±  TBD  VDC  power  line  to  the  CFTP 
payload. 

The  MidSTAR-1  SC  shall  provide  two  switched  5  VDC  +  1  VDC  power  lines  to  the  ICSat 
payload. 

5.4.2.  Power  Quality 

No  requirement. 

5.4.3.  Loads 

No  requirement. 

5.4.4.  Grounding 

The  MidSTAR-1  team  shall  negotiate  grounding  interfaces  with  each  experimenter. 

5.4.5.  Power  Draw  Profiles 

The  MidSTAR-1  SC  shall  provide  experiments  with  power  across  each  power  line  as  negotiated 
with  each  experimenter. 

[Current  estimates  for  power  draw  for  each  power  line  are  given  in  Table  5-lbelow.  The  values 
given  here  are  unmargined.] 


Table  5-1:  Power  Draw  of  MidSTAR-1  Payloads 


Component 

Power  States,  W 

Survival 

Standby 

Operating 

Peak 

CFTP 

0.0 

0.5 

5.0 

11.0 

ICSat 

Comm  Block 

0.0 

0.0 

4.0 

4.0 

Amplifier 

0.0 

0.0 

10.0 

10.0 

[Survival  power  is  the  power  that  must  be  provided  to  the  payload  during  nominal  operations 
when  the  payload  is  not  in  standby  or  operating.  Standby  power  is  defined  as  the  average  power 
consumption  of  an  instrument  in  a  condition  where  it  is  not  collecting  data  but  could  start  doing 
so  instantaneously  without  warm  up.  Operational  power  is  defined  as  the  average  power 
consumption  of  a  component  during  the  period  it  is  operating.  Peak  power  is  the  maximum 
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instantaneous  power  that  a  component  will  draw;  this  does  not  include  power  surges  of  less  than 
1.0  milliseconds. 

The  MidSTAR-1  SC  shall  provide  sufficient  power  to  the  payloads  to  operate  all  experiment 
modes.  [Payload  power  consumption  for  typical  operations  modes  and  duty  cycles,  assuming  a 
96-minute  orbit  duration,  are  shown  in  Table  5-2  below.] 


Table  5-2:  Power  Profiles  of  the  MidSTAR-1  Payloads 


Experiment  Ops  Mode 

Power  Draw,  W 

Fraction  of  Orbit, 
minutes  or  %  of  orbit 

Frequency  of 
Operations 

CFTP  Processor 
Operations 

5 

100% 

Continuous 

CFTP  Configuration 
Change 

TBD 

TBD 

Once  per  week 

CFTP  Standby 

0.5 

TBD 

Only  as  needed 

ICSat  Data  Transmission 

14.0 

11  min 

Each  pass  over 
SGS 

ICSat  Standby 

4.0 

85  min 

Out  of  view  of 
SGS 

5.5.  Electrical  Signals  (Inputs  and  Outputs) 

5.5.1.  Discrete  Analog  Signals 

No  requirement. 

5.5.2.  Discrete  Bi-Level  Signals 

No  requirement. 

5.5.3.  Digital  Signals 

The  MidSTAR-1  SC  shall  provide  one  RS-422  asynchronous  serial  interface  at  115kbps. 

The  MidSTAR-1  SC  shall  provide  one  synchronous  serial  data  channel  with  the  ICSat  payload. 
The  MidSTAR-1  team  shall  negotiate  data  bus  specifications  and  data  transfer  protocols  with  the 
ICSat  experimenter. 

5.6.  Software  Interfaces 

The  MidSTAR-1  SC  shall  provide  a  computer  system  to  execute  the  ICSat  Hosted  Software. 

The  host  computer  system  shall  be  a  PC- 104  or  equivalent  platform  with  Linux  operating 
system.  The  host  computer  system  shall  provide  at  least  1  Mbyte  of  storage  space  for  the  Hosted 
Software.  The  MidSTAR-1  team  shall  negotiate  the  Hosted  Software  interfaces,  protocols, 
permissions,  and  resource  management  with  the  ICSat  experimenter. 
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5. 7.  Command  and  Data  Requirements 

5.7.1.  Time/Clock  Reference  Requirements 

No  requirement. 

5.7.2.  Command  Requirements 

5.7.2. 1.  Command  Scheme 

The  MidSTAR-1  SC  shall  provide  the  capability  for  experimenters  to  execute  real-time 
commands  (forwarded  to  the  payload  immediately  upon  receipt)  and  stored  commands 
(forwarded  to  the  payload  according  to  a  time  indicator  within  the  command  or  a  header. 

5.7. 2.2.  Command  Loading 

The  MidSTAR-1  SC  shall  provide  the  following  commands  to  CFTP: 

1.  A  periodic  watchdog  timer  command  to  the  experiment  in  order  to  provide  a  maskable 
capability  for  asserting  experiment  reset 

2.  A  command  to  place  the  experiment  into  standby  mode 

3.  A  command  to  place  the  experiment  into  active  mode 

The  MidSTAR-1  SC  shall  be  able  to  execute  the  ICSat  Hosted  Software  application  upon 
command.  The  MidSTAR-1  SC  shall  provide  commands  to  switch  the  power  lines  to  ICSat 
experiment  hardware.  The  MidSTAR-1  team  shall  negotiate  additional  ICSat  commands  and 
command  formats  with  the  ICSat  experimenter. 

5.7.3.  Telemetry  Requirements 

The  MidSTAR-1  SC  shall  monitor  and  report  payload  temperatures  and  power  supply  line 
voltages  and  currents.  This  data  shall  be  provided  to  the  experimenters  to  assist  in  payload  data 
analysis.  The  SC  shall  monitor  these  points  with  enough  resolution  to  discern  when  the  payloads 
are  on. 

5.7.4.  Data  Management  Requirements 

5.7.4.I.  Data  Volume 

The  MidSTAR-1  SC  shall  accept  a  maximum  of  1  Mbytes  (unmargined)  of  CFTP  data  per  day 
from  the  payload.  The  MidSTAR-1  team  shall  negotiate  additional  requirements  with  the  CFTP 
experimenter.  The  MidSTAR-1  SC  shall  accept  a  maximum  of  1  Mbytes  (unmargined)  of  CFTP 
data  per  day  from  the  SGS  for  transfer  to  the  CFTP  payload.  The  MidSTAR-1  SC  shall  provide 
a  minimum  of  2  Mbyte  (unmargined)  of  data  storage  for  the  exclusive  use  of  the  CFTP  payload. 

The  MidSTAR-1  SC  shall  accept  a  maximum  of  30  Mbytes  (unmargined)  of  ICSat  stored  data 
files  to  be  transported  over  the  experimental  communications  link.  [This  storage  requirement 
does  not  include  requirements  driven  by  the  Hosted  Software.]  The  MidSTAR-1  SC  shall 
provide  a  minimum  of  30  Mbytes  of  mass  memory  for  the  exclusive  use  of  the  ICSat  payload. 
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[All  experiment  data  requirements  include  experiment  overhead,  but  do  not  include  SC-added 
overhead.] 

5.7.4.2.  Data  Latency 

The  MidSTAR-1  SC/SGS  system  shall  retrieve  payload  downlink  data  within  24  hours  of  when 
the  data  was  generated. 

5.7.4.3.  Data  Quality 

The  SC  shall  ensure  that  CFTP  data  resident  on  SC  systems  do  not  experience  more  than  1 
uncorrected  bit  error  per  day.  The  MidSTAR-1  SC-to-SGS  (from  data  bus  interface  with  the 
payload  to  placement  on  data  distribution  server)  system  shall  introduce  bit-errors  into  CFTP  at  a 
rate  no  greater  than  2  in  105,  averaged  over  the  total  volume  of  data  transferred. 

The  MidSTAR-1  SC-to-SGS  (from  data  bus  interface  with  the  payload  to  placement  on  data 
distribution  server)  system  shall  introduce  bit-errors  into  ICSat  date  at  a  rate  no  greater  than  1  in 
105,  averaged  over  the  total  volume  of  data  transferred. 

5.7.4.4.  Payload  Data  Management  Functions 

The  SC  shall  accept  data  from  the  payloads  as  they  are  generated.  The  SC  shall  provide 
buffering  and  routing  of  uploaded  data  to  the  payloads.  The  SC  shall  provide  the  sole  on-orbit 
payload  data  storage  for  both  experiments. 

The  SC  shall  conduct  all  data  management  activities  for  payload  data  that  is  in  storage, 
including,  but  not  limited  to:  memory  checks,  memory  purges,  identify  data  blocks,  perform 
error  detection  and  correction,  and  enforce  experiment  data  separation. 

The  SC  shall  conduct  all  data  bus  management  between  the  payloads  and  the  SC  subsystems, 
including,  but  not  limited  to:  enforcing  allowable  latency  from  “message  ready”  to  “message 
handled”,  avoidance  of  data  overwrite,  preventing  early  data  fetch,  and  arbitrating  data  access 
contention. 

The  SC  shall  be  able  to  route  uplinked  commands  to  the  SC.  The  SC  shall  be  able  to  route  SC 
telemetry  to  the  ICSat  payload  for  transmission  to  the  ground  station.  The  SC  shall  be  able  to 
forward  data  from  the  ICSat  payload  to  the  CFTP  payload,  and  from  the  CFTP  payload  to  the 
ICSat  payload. 

5.8.  Environmental  Constraints 

5.8.1.  Static  and  Quasi-Static  Loads 

The  MidSTAR-1  processes  and/or  SC  shall  not  expose  the  experiment  payloads  to  static  or 
quasi-static  loads  greater  than  those  the  MidSTAR-1  team  derives  for  the  experimenters. 

5.8.2.  Random  Vibration 

The  MidSTAR-1  processes  and/or  SC  shall  not  expose  the  experiment  payloads  to  random 
vibration  loads  greater  than  those  the  MidSTAR-1  team  derives  for  the  experimenters. 
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5.8.3.  Acoustics 

The  MidSTAR-1  processes  and/or  SC  shall  not  expose  the  experiment  payloads  to  acoustic  loads 
greater  than  those  the  MidSTAR-1  team  derives  for  the  experimenters. 

5.8.4.  Shock 

The  MidSTAR-1  processes  and/or  SC  shall  not  expose  the  experiment  payloads  to  shock  loads 
greater  than  those  the  MidSTAR-1  team  derives  for  the  experimenters. 

5.8.5.  Depressurization 

The  MidSTAR-1  processes  and/or  SC  shall  not  expose  the  experiment  payloads  to 
depressurization  at  rates  greater  than  4.14  kPa/sec. 

5.8.6.  Humidity 

The  MidSTAR-1  processes  and/or  SC  maintain  the  CFTP  and  ICSat  payload  in  a  humidity  range 
in  which  condensation  is  avoided  and  the  potential  for  inadvertent  electrostatic  discharge  is  low. 

5.8.7.  Radiation 

No  requirement. 

5.8.8.  Thermal 

5.8.8.I.  Temperature  Limits 

The  MidSTAR-1  processes  and  /or  SC  shall  maintain  CFTP  and  ICSat  payload  elements  within 
the  temperature  ranges  given  in  Table  5-3. 


Table  5-3:  MidSTAR-1  Payload  Temperature  Limits 


Payload  Component 

Survival 

Temperature 

Range 

(°C) 

Operating 

Temperature 

Range 

(°C) 

Notes 

Low 

High 

Low 

High 

CFTP 

ICSat 

Amplifier 

-40 

90 

-25 

80 

Communications  Block 

-40 

90 

-25 

80 

Antenna 

-40 

90 

N/A 

N/A 

5.8.8.2.  Thermal  Flux  Limits 

No  requirement. 

5.8.9.  Contamination 

From  receipt  of  the  experiment  payloads  to  the  transfer  of  the  SV  to  the  IC,  the  MidSTAR-1 
team  shall  maintain  the  experiment  payloads  in  a  cleanliness  environment  of  Class  100,000  or 
better.  Exceptions  to  this  condition  shall  be  coordinated  with  STP. 
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5.8.10.  Electromagnetic  Compatibility 

The  MidSTAR-1  team  shall  ensure  that  the  SV  operates  without  anomaly,  as  defined  in  Section 
3.1  of  MIL-STD-1541A.  Ground  Support  Equipment  (GSE)-generated  electromagnetic 
interference  (EMI)  shall  not  degrade  the  MidSTAR-1  team’s  ability  to  test  and  operate  the  SV  in 
normal  test  environments. 

[The  CFTP  shall  to  meet  MIL-STD46 1/462  requirements  for  radiated  emissions,  as  tailored 
MidSTAR-1  team  and  the  IC. 

When  not  conducting  communications  experiments,  the  ICSat  payload  shall  comply  with  MIL- 
STD-461  requirements  for  radiated  emissions,  as  tailored  by  the  MidSTAR-1  team  and  the  IC. 

In  addition,  during  communications  events,  ICSat  will  transmit  in  a  frequency  band  of  2  MHz 
bandwidth,  centered  on  frequency  2.4  GHz. 

5.9.  Positioning  and  Orientation  Requirements 

5.9.1.  Orbit  Maintenance 

No  requirement. 

5.9.2.  Attitude  Control  and  Knowledge 

No  attitude  knowledge  or  control  requirement  for  CFTP. 

The  MidSTAR-1  SC  shall  point  the  boresight  of  the  ICSat  antenna  within  90  degrees  of  the  SV 
instantaneous  local  nadir  axis. 

5.10.  Integration  and  Test  Support  Requirements 

The  MidSTAR-1  team  shall  provide  sufficient  workspace  and  supplies  for  the  experimenters 
throughout  the  integration  and  test  period,  as  negotiated  with  the  experimenters.  “Workspace 
and  supplies”  shall  include  work  areas,  furnishings,  office  supplies,  other  minor  supplies  (e.g. 
cleanroom  suits),  access  to  standard  wall  electrical  outlets,  access  to  telephone  lines,  and  access 
to  an  internet  server. 

All  personnel  handling  the  payloads  shall  use  standard  electrostatic  discharge  precautions.  All 
personnel  working  near  the  ICSat  antenna  shall  observe  a  keep-out/no-hands  zone  around  the 
antenna. 

5. 1 1.  Operations  Support  Requirements 

5.11.1.  Facility  Requirements 

No  requirement. 

5.11.2.  Personnel  Training  Requirements 

The  MidSTAR-1  team  shall  establish  training  requirements  for  the  experimenters.  The 
MidSTAR-1  shall  train  the  experimenters  in  accordance  with  their  requirements  as  needed. 
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5.11.3.  Payload  Operations  Requirements 

[Upon  application  of  power,  the  CFTP  payload  will  perform  a  self-test  and  generate  status 
reports.]  The  MidSTAR-1  SC  shall  be  able  to  accept  data  from  the  CFPT  payload  at  any  time 
while  CFTP  is  powered  on. 

The  MidSTAR-1  SC  shall  time-stamp  all  data  packets  from  CFTP.  The  time-stamps  shall  be 
correlated  to  Universal  Time  Coordinated  (UTC)  within  ±1  second. 

The  SC  shall  maintain  ICSat  experiment  data  until  deleted  by  ground  command. 

5.11.4.  Mission  Planning  Requirements 

The  MidSTAR-1  team  shall  provide  an  operations  plan  that  outlines  SC  on-orbit  check-out, 
experiment  payload  check-out,  normal  operations,  contingency  operations,  and  mission  end-of- 
life.  The  operations  plan  shall  demonstrate  that  the  MidSTAR-1  mission  will  satisfy  all  mission 
requirements.  The  normal  operations  plan  should  ideally  describe  the  progression  of  activities 
that  lead  to  increasing  levels  of  mission  success. 

5.11.4.1.  Ephemeris  Requirements 

CFTP  has  no  predictive  or  real-time  ephemeris  knowledge  requirement.  ICSat  requires  orbit 
elements  or  ephemeris  to  permit  predictions  of  SV  passes  over  the  SGS  ground  station.  ICSat 
requires  accuracy  of  the  orbital  elements  or  ephemeris  to  be  sufficient  to  predict  pass  times  with 
predicted  rise  time  accurate  to  within  +1  minutes  of  the  actual  rise  for  up  to  five  days  from  the 
epoch  of  the  element  set  or  ephemeredes. 

5.11.4.2.  Meteorological  Services 

No  requirement. 

5.11.4.3.  Space  Weather  Services 

No  requirement. 

5.11.5.  Data  Distribution  and  Analysis  Requirements 

The  MidSTAR-1  team  shall  provide  orbit  elements  and/or  ephemeris  to  CFTP  to  correlate 
experiment  processor  faults  to  orbit  location.  The  accuracy  of  orbit  elements  and/or  ephemeris 
shall  be  sufficient  to  locate  each  event  with  an  accuracy  of  less  than  or  equal  to  50  km. 

ICSat  has  no  requirements  for  post-pass  orbit  elements  or  ephemeris. 

The  MidSTAR-1  team  shall  make  all  downloaded  experiment  data  files  available  to  the 
experimenters  within  24  hours  of  receiving  the  download. 
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6.  Launch  Service  Requirements 

6.1.  LV  Coordinate  System 

For  each  secondary  interface  on  the  ESPA,  a  local  right-handed  coordinate  system  is  defined 
with  the  origin  in  the  SSIP  and  centered  in  the  flange.  The  positive  X-axis  is  defined 
perpendicular  to  the  SSIP  and  directed  toward  the  fairing.  The  positive  Y-axis  lies  in  the  SSIP, 
is  parallel  with  the  LY  longitudinal  axis,  and  is  directed  toward  the  primary  payload  station.  The 
positive  Z-axis  is  orthogonal  to  the  X-  and  Y-axes,  with  its  direction  dictated  by  the  right-hand 
rule.  All  MidSTAR-1  data  submitted  to  the  IC  shall  reference  this  coordinate  system. 

6.2.  Interface  Allocations 

The  MidSTAR-1  team  shall  count  the  Lightband  separation  system  as  part  of  the  space  vehicle 
for  all  purposes. 

6.3.  Physical  Interfaces 

6.3.1.  Physical  Properties 

6.3.1.1.  Dimensions 

The  MidSTAR-1  SV  shall  fit  within  a  60.9  cm  x  60.9  cm  x  96.5cm  static  envelope;  small 
excursions  beyond  the  envelope  may  be  coordinated  with  the  STP-1  SPO.  The  Lightband 
separation  system  and  all  payload  components  shall  be  contained  within  the  volume  envelope. 

6.3.1.2.  Mass  Properties 

The  SV  mass  shall  not  exceed  150  kg.  For  purposes  of  mass  calculation,  the  SV  shall  account 
for  the  entire  Lightband  system  in  its  mass  budget. 

The  SV  center  of  mass  shall  be  less  than  or  equal  to  48  centimeters  from  the  secondary  standard 
interface  plane  with  ESPA  (along  the  positive  x-axis  as  defined  in  the  Secondary  Payload 
Planner’s  Guide.)  The  center  of  gravity  excursion  from  the  SV  centerline  shall  be  chosen  to 
maintain  SV  controllability  with  the  resultant  tip-off  rate,  and  ensure  satisfactory  deployment 
clearance. 

6.3.1.3.  Surface  Properties 

This  section  not  used. 

6.3.2.  Mounting,  Alignment  and  Clocking 

The  SV  design  shall  permit  reasonable  access  to  the  Lightband  bolts  and  electrical  connectors 
during  SV-to-ESPA  integration.  The  SV  design  shall  permit  reasonable  access  to  test  ports 
and/or  arming  plugs  after  integration  to  the  ESPA  and  during  post-encapsulation  processing,  as 
appropriate. 
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6.3.3.  Moving  Parts  and  Deployable  Mechanisms 

Any  moving  part  or  deployable  mechanism  shall  be  inhibited  to  ensure  it  does  not  move  or 
deploy  prematurely. 

6.3.4.  Electrical  Connectors  and  Harnesses 

The  MidSTAR-1  SC  electrical  connections  to  the  LV  and  the  launch  umbilical  shall  be  routed 
through  the  Lightband  15 -pin  connector. 

6.4.  Electrical  Power 

6.4.1.  Umbilical  Power 

The  MidSTAR-1  SV  shall  require  no  more  than  two  pairs  of  electrical  power  lines  through  the 
umbilical  harness  while  mated  to  the  ESPA. 

6.4.2.  LV  Power 

The  MidSTAR-1  SV  shall  not  require  LV -provided  power  at  any  time. 

6.4.3.  SC  Power 

If  the  MidSTAR-1  team  decides  to  forego  trickle  charge  service  through  the  umbilical,  the 
MidSTAR-1  SV  electrical  power  function  shall  remain  viable  for  ninety  contiguous  days  without 
maintenance  or  reconditioning. 

6.5.  Electrical  Signals  (Inputs  and  Outputs) 

6.5.1.  Umbilical  Signals 

The  MidSTAR-1  SV  shall  require  no  more  than  two  pairs  of  digital  telemetry  lines  through  the 
umbilical  harness  while  mated  to  the  ESPA. 

6.5.2.  LV  Signals 

The  MidSTAR-1  SV  shall  provide  a  loopback  for  one  pair  of  wires  from  the  LV  to  serve  as  a 
separation  indicator. 

6.6.  Command  and  Data  Requirements 

[The  launch  vehicle  shall  supply  the  redundant  signal  for  Lightband  initiation.] 

6.7.  LV  En  vironments 

The  STP-1  SPO  will  provide  the  MidSTAR-1  team  with  predicted  launch  loads  (quasi-static, 
random  vibration  and  shock)  when  available.  Until  the  predicted  loads  are  available,  the 
MidSTAR-1  team  shall  apply  the  loads  given  in  Sections  6.7.1  and  6.7.2  below  for  design.  All 
other  environments  are  as  specified  in  the  Delta  IV  Payload  Planners  Guide.  The  MidSTAR-1 
team  shall  satisfy  any  additional  requirements  imposed  by  the  STP-1  SPO. 
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6.7.1.  Static  and  Quasi-Static  Loads 

Until  predicted  loads  are  available,  the  MidSTAR-1  team  shall  use  design  load  factors  of  10.6  g 
in  the  LV  axial  (MidSTAR-1  +  Y-axis)  and  10.6  g’s  LV  lateral  (MidSTAR-1  +  Z-axis),  applied 
concurrently  and  at  the  SV  center  of  gravity. 

6.7.2.  Fundamental  Frequency 

The  SV  shall  be  designed  with  a  minimum  first  fundamental  frequency  of  35  Hz  in  both  the  LV 
axial  (MidSTAR-1  +  Y-axis)  and  LV  lateral  (MidSTAR-1  +  Z-axis)  directions. 

6.7.3.  Random  Vibration 

[To  be  supplied] 

6.7.4.  Acoustics 

[To  be  supplied] 

6.7.5.  Shock 

[To  be  supplied] 

6.7.6.  Depressurization 

The  MidSTAR-1  SC  shall  tolerate  depressurization  at  rates  up  to  4.14  kPa/sec. 

6.7.7.  Humidity 

[To  be  supplied] 

6.7.8.  Contamination 

The  MidSTAR-1  team  shall  comply  with  the  STP-1  contamination  plan,  when  available.  The 
following  requirements  apply  until  superceded  by  the  requirements  in  the  contamination  plan. 

All  flight  hardware,  and  all  GSE  that  will  accompany  flight  hardware  into  thermal  and/or  thermal 
vacuum  chambers,  shall  contain  only  low-outgassing  materials  (total  mass  loss  <  1.0%  and 
collected  volatile  condensable  materials  <  0.10%);  else,  the  SV  and  the  accompanying  GSE  shall 
be  subjected  to  a  thermal  vacuum  bake-out  to  achieve  equivalent  low-outgassing  properties. 
Additionally,  the  MidSTAR-1  team  shall  be  prepared  to  provide  a  list  of  materials  to  the  STP-1 
SPO  upon  request. 

From  payload  integration  on,  all  flight  hardware  and  accompanying  GSE  shall  be  maintained  in 
Class  100,000  environments  at  all  times  (some  brief  violations  may  be  tolerated  with  approval 
from  STP).  Prior  to  shipping  to  the  launch  site,  the  exterior  of  the  SV  and  accompanying  GSE 
shall  be  verified  to  be  visibly  clean.  At  the  launch  site,  the  MidSTAR-1  team  shall  comply  with 
all  cleanliness  procedures  imposed  by  the  IC. 

6.7.9.  Thermal 

[To  be  supplied] 
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6.7.10.  Electromagnetic  Compatibility 

The  MidSTAR-1  SV,  GSE,  and  procedures  shall  comply  with  the  requirements  provided  in  the 
STP-1  Electromagnetic  Compatibility  Analysis,  when  available.  This  analysis  will  determine  the 
EMI  concerns  for  all  SVs  on  the  STP-1  mission. 

The  MidSTAR-1  communications  subsystem  and  the  ICSat  experiment  shall  not  radiate  through 
RF  antennas  while  in  the  launch  base  integration  facility  or  while  the  SV  is  mated  to  the  ESPA. 

If  post  LV-integration  (especially  post-encapsulation)  tests  are  required,  communications 
between  the  SV  and  the  GSE  shall  be  conducted  over  cables. 

6.8.  Integration  and  Test  Support  Requirements 

Prior  to  integration  to  the  ESPA,  the  MidSTAR-1  SV  shall  be  cleaned  to  VC  7  Cleanliness  level, 
as  defined  in  the  Delta  IV  Payload  Planners’  Guide,  Table  4-4. 

6.9.  Launch  Operations  Requirements 

6.9.1.  Countdown 

No  requirement. 

6.9.2.  Launch  and  Ascent 

The  MidSTAR-1  SV  shall  be  powered  off  during  ascent. 

6.9.3.  Separation 

The  MidSTAR-1  SV  shall  not  contact  any  other  SV  on  the  IPS  during  separation. 

6.10.  Launch  Base  Requirements 

6.10.1.  Security 

The  MidSTAR-1  team  shall  conform  to  the  security  requirements  in  place  at  the  launch  site. 

6.10.2.  Range  Safety 

All  launch  site  operations  shall  be  compliant  with  the  requirements  of  Eastern  and  Western 
Range  (EWR)  127-1  as  applicable  to  the  launch  site. 
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7.  Operations  Service  Requirements 

7. 1.  Ground  System  Interface  Requirements 

This  section  not  used. 

7.2.  Personnel  Training  Requirements 

This  section  not  used. 

7.3.  Space  Vehicle  Management  Requirements 

This  section  not  used. 

7.4.  Mission  Planning  Requirements 

This  section  not  used. 

7.5.  Data  Distribution  and  Analysis  Requirements 

This  section  not  used 
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APPENDIX  B:  CFTP  SCHEMATIC  DIAGRAMS 


Appendix  B  contains  the  schematic  diagrams  depicting  the  pin-outs  of 
each  of  the  CFTP’s  devices.  Figure  57  is  shows  the  PC/104  interface,  Intel  flash 
memory,  Xilinx  PROM,  voltage  regulators,  and  oscillator.  Figure  58  shows  the 
pin-out  for  the  Configuration  Controller  FPGA,  and  Figure  59  shows  the  pin-out 
for  the  Configurable  Processor  FPGA.  Figure  60  shows  the  SDRAM  pin  assign¬ 
ments. 
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Figure  57.  CFTP  Schematic  Sheet  1 
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Figure  59.  CFTP  Schematic  Sheet  3 
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APPENDIX  C:  CFTP  PCB  LAYER  SCHEMATICS 


Appendix  C  contains  the  layer  detail  of  the  CFTP  PCB.  Figure  61  is  the 
top  layer,  including  silk  screen.  Figure  62  is  the  top  layer  mask.  Figure  63  is  the 
first  mid-layer.  Figures  64  through  66  are  the  Vccint  (+2.5V),  Ground,  and  VCco 
(+3.3V)  planes,  respectively.  Figures  67  and  68  are  mid-layers  two  and  three. 
Figure  69  is  the  bottom  layer  mask.  Figure  70  shows  the  bottom  layer,  including 
silk  screen,  and  Figure  71  shows  the  PCB  Dimensions. 
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Figure  61.  CFTP  PCB  Top  Layer,  Including  Silk  Screen 
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Figure  62.  CFTP  PCB  Top  Layer  Mask 
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Figure  63.  CFTP  PCB  First  Mid-Layer 
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Figure  64.  CFTP  PCB  Vccint  (+2.5V)  Plane 
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Figure  65.  CFTP  PCB  Ground  Plane 
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Figure  66.  CFTP  PCB  \ZCC0  (+3.3V)  Plane 
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Figure  67.  CFTP  PCB  Mid-Layer  Two 
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Figure  68. 


CFTP  PCB  Mid-Layer  Three 
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Figure  69.  CFTP  PCB  Bottom  Layer  Mask 
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Figure  70.  CFTP  PCB  Bottom  Layer,  Including  Silk  Screen 


213 


CJ  38 


APPENDIX  D:  GLOSSARY 


ALU 

Arithmetic  Logic  Unit 

AMD 

Advanced  Micro  Devices 

ASIC 

Application  Specific  Integrated  Circuit 

BGA 

Ball  Grid  Array 

CAD 

Computer  Aided  Design 

CC 

Configuration  Controller 

C&DH 

Command  and  Data  Handler 

CDR 

Critical  Design  Review 

CFTP 

Configurable  Fault-Tolerant  Processor 

CLB 

Configurable  Logic  Block 

C-Module 

Combinatorial  Module 

CMOS 

Complementary  Metal  Oxide  Semiconductor 

COTS 

Commercial-Off-The-Shelf 

CP 

Configurable  Processor 

CPE 

Configurable  Processor  Experiment 

CRC 

Cyclic  Redundancy  Check 

DC 

Direct  Current 

DD 

Displacement  Damage 

DLL 

Delay  Lock  Loop 

DOD 

Department  of  Defense 

DRAM 

Dynamic  Random  Access  Memory 

DSP 

Digital  Signal  Processing 

ECC 

Error  Correction  Code 

ED  AC 

Error  Detection  And  Correction 

epi 

epitaxial  layer 

FPGA 

Field  Programmable  Gate  Array 

GCR 

Galactic  Cosmic  Rays 

GEO 

Geostationary  Earth  Orbit 

GeV 

Giga-electron  Volt 

GRM 

General  Routing  Matrix 
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GTO 

Geosynchronous  Transfer  Orbit 

HDL 

Hardware  Description  Language 

1C 

Integrated  Circuit 

I/O 

Input/Output 

IOB 

Input/Output  Block 

ISP 

In-System  Programmable 

JTAG 

Joint  Test  Action  Group 

KeV 

Kilo-electron  Volt 

LEO 

Low  Earth  Orbit 

LET 

Linear  Energy  Transfer 

MEO 

Medium  Earth  Orbit 

MeV 

Mega-electron  Volt 

MidSTAR-1 

Midshipmen  Science  and  Technology  Application  Re¬ 
search  Mission  1 

MIPS 

Million  Instructions  Per  Second 

MISR 

Multi-angle  Imaging  SpectroRaiodmeter 

MOS 

Metal  Oxide  Semiconductor 

NASA 

National  Aeronautics  and  Space  Administration 

NORAD 

North  American  Aerospace  Defense  Command 

NPS 

Naval  Postgraduate  School 

NPSAT1 

Naval  Postgraduate  School  Satellite  1 

NRE 

Non-Recurring  Engineering 

ONO 

Oxide-Nitride-Oxide 

OTP 

One-Time  Programmable 

PAL 

Programmable  Array  Logic 

PANSAT 

Petit  Amateur  Navy  Satellite 

PC 

Personal  Computer 

PCB 

Printed  Circuit  Board 

PLA 

Programmable  Logic  Unit 

PLD 

Programmable  Logic  Device 

PLICE 

Programmable  Low  Impedance  Circuit  Element 

QFP 

Quad  Flat  Pack 

RADHARD  Radiation  Hardened 
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rads 

Radiation  Absorbed  Dose 

RAM 

Random  Access  Memory 

R-Cell 

Register  Cell 

RISC 

Reduced  Instruction  Set  Architecture 

RLOS 

Random  Left-Over  Stuff 

ROM 

Read  Only  Memory 

SAA 

South  Atlantic  Anomaly 

SCR 

Silicon  Controller  Rectifier 

SDRAM 

Synchronous  Dynamic  Random  Access  Memory 

SEE 

Single  Event  Effect 

SEL 

Single  Event  Latchup 

SERB 

Space  Experiments  Review  Board 

SET 

Single  Event  Transient 

SEU 

Single  Event  Upset 

S-Module 

Sequential  Module 

SOC 

System-On-A-Chip 

SOI 

Silicon  on  Insulator 

SPLD 

Serial  (or  Sequential)  Programmable  Logic  Device 

SRAM 

Static  Random  Access  Memory 

SSAG 

Space  Systems  Academic  Group 

STP 

Space  Test  Program 

TID 

Total  Ionizing  Dose 

TMR 

Triple  Modular  Redundant 

USAFA 

United  States  Air  Force  Academy 

USNA 

United  States  Naval  Academy 
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